One of our biggest concerns as business analysis practitioners is scope: how do we define scope, how do we guarantee that we can deliver everything that satisfies the scope, and how do we ensure that we don’t stray outside the scope?
In other words, how do we place our hand upon the BABOK and swear that the analysis we give will be the scope, the whole scope, and nothing but the scope?
When most people think about scope, they think about the boundaries of an area or domain, constraining the breadth of what we look at so that we focus more sharply on those processes and activities that require change.
This definition is inherently two-dimensional.
Imagine an episode of Doctor Who, where he and his trusty sidekick have to work out how they can get across a puddle. If the Doctor thought about problems in just two dimensions, he might think he can solve the problem of crossing the puddle by looking only at how long and wide it is; because this tells him whether he can step or jump across it.
This perspective is probably sufficient early in a project where we want to define the business scope, but the real world is not just two-dimensional.
Within and below the business scope is the solution scope. Most problems I have seen with scope are with the solution scope; that is, how simple or complex will the solution be, are we happy with manual processes alone, with some minimal technical support of the main scenario, or do we need full automation of every possible scenario.
This takes the definition into the third dimension, i.e. how deep it is.
So now Doctor Who could use his sonic screwdriver to gauge how deep the puddle is; which tells him at least whether he can easily walk across it, wade through it up to his waist, or that he’ll need a boat.
The deeper it is the more expensive or time-consuming it will be; but we need to know that before we start, right? Too many projects are approved to go before the solution options have been considered, and this is one of the most common reasons for cost and time blow-out.
And of course, one of the biggest issues for our projects is that they assume the scope is fixed at the outset and work to deliver that; only discovering toward the end that the scope has shifted or grown so that they will struggle to get sign off or worse still, the business will sign it off and never use it.
Of course, this is about the state of something over time, and so introduces the fourth dimension: time.
Back to our puddle; if the Doctor looked at it in the morning, then popped off for a few hours, when he came back the puddle may have dried up, run somewhere else, or grown in area or depth if the rain continued. He cannot then hope to get across it the same way, and if it’s gone completely he doesn’t need to bother at all.
We should never assume the scope stays fixed; and how can we deal with that?
Denial: Some organisations seek to constrain this by enforcing strict change control, in effect putting brakes on change. While this means the scope stays the same during the life of the project, it doesn’t mean it will be fit for purpose when it’s ready for delivery – so we get cost and time blow-out as we redress that.
Acceptance: Smarter organisations accept that scope will change; they baseline the business scope, and work in smaller chunks to elaborate the solution scope on an ‘as needed’ basis. They can continuously check that the scope is still sound, and if it has changed, avoid doing work that will be unnecessary. Although this could end up with only delivering 80% of the original solution scope, the project can still end on time and within budget … or they can choose to continue if that final 20% is really needed.
At the end of the episode, as Doctor Who vanishes off on his next adventure, we’re faced with what’s left and have to ask:
Please note: this article was first published on BATimes.com.