Scoping a software project can be real heavy-lifting for the mind. Migraine territory if you’re not careful.
It’s not because there is a lot to cover – trust me, there is loads to cover but there are well-trodden pathways to follow to make sure nothing gets overlooked; process mapping, user research, business objectives, the list goes on…
No, the breadth isn’t the issue, it’s how deep it can go.
It’s when you go really deep that people reveal the most useful insights. That’s why you do it. Digging into the reasons behind why you want this software, and what it can do for your business.
It often takes the same question being asked a few different ways; different enough for the other person not to register. Software scoping can almost become therapy for whoever’s software is being scoped. It offers a glimpse into potential business transformations that haven’t happened yet. It takes them a few steps away from today’s constraints and realities.
Software scoping: chicken soup for your business processes and workflows
At Helastel, we like to think we do the ‘deep’ bit particularly well. It stops us being one of those bespoke software development companies that says yes to everything without questioning why. This is not beligerance, it makes for better software; better suited to what the business is trying to do, even if the business can’t articulate that or might initially be saying they need something different.
We certainly steer clear of allowing ourselves or our clients to get too introspective during this process. There are enough mental gymnastics going on during the software scoping process without us lighting joss sticks and freaking everyone out with profound existential questions.
Software scoping, remember, is extremely important to the development of great software. Hence any suggestion that this is somehow optional, should be quickly nipped in the bud.
Go deep, but don’t get caught in the weeds
Thinking about it, I can see how some clients who come from a very business management background might find the software scoping process a little daunting. It probably doesn’t help to have me sitting across the table from you, barely able to contain my enthusiasm (and possibly even cackling in a slightly evil-sounding way) for the discussion that is about to commence.
For some business folk, the most daunting thing of all is the expectation that you’ll know enough about software to avoid coming across to software people as some kind of doofus.
If so, please DO NOT WORRY. Let the software developers worry about those details. You just stay focused on the big picture motivations for why you are doing this; whatever it was that made you think software was the answer. Don’t waste your time boning up on software jargon. Be ready to answer questions about pretty much anything to do with your business. And come armed with some questions of your own too.
Software talk? Give me plain speaking any day
I don’t think software scoping is made any faster, easier or more successful by pumping it full of Kanban, Bootstrap and other funny-sounding names for software-related stuff.
In fact, too much of this works to obscure what can be a truly enlightening, refreshing and – dare I say – rather magical process of sketching out a map for a seismic business change enabled by technology. That’s what you get from software scoping.
I find the best person to meet in a software scoping session is the archetypal no-nonsense business owner who prefers dealing in unvarnished truths to games of buzzword bingo. You don’t lock horns with this person, who sit at their feet and listen. You certainly don’t pester them with software this and software that. Ask the right questions about their business and where they want it to go; some very direct ones, some that come out of left field.
“Please,” you think. “Please just say it like it is.” And when they do the headache clears like the best paracetamol you ever took.