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.
How deep is it?
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.
The only thing constant is change
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:
- What has been your experience of problems with scope?
- How does your organisation seek to cope with changes in scope?
- Are there any other approaches that you have seen work?
- And, most importantly, what was so important about the puddle and couldn’t the Doctor just have used the TARDIS to reappear on the other side?