Scope should be so obvious to most project managers, that perhaps there isn’t much to be said here. On the other hand, there is no harm in revisiting the basics and possibly uncovering some not-so-obvious aspects.
By having a well-defined scope, we can plan with certainty, execute with confidence, and deliver exactly what the stakeholders want. It’s a great idea, but have you ever seen it work like that? No, me neither.
More often, the initial scope is just that: a starting point. The destination may not be clear, but the initial scope points the direction. It may form a baseline for subsequent adaptation, under change control.
Nevertheless, there is tremendous value in attempting to define the scope at the outset, to whatever level of detail seems appropriate. Apart from anything else, it provides an opportunity for high-quality conversation with senior stakeholders – who may not be aligned, and may have completely different ideas of project success. So by writing down a proposed scope, along with accompanying project success criteria, the project manager can facilitate the process of convergence between stakeholders.
I was once given a project whose total initial statement of scope was “let’s do something about security”. Too loose a statement of scope? No, not a bit of it – that’s my kind of project! What an ideal opportunity to spend time with senior executives, as well as subject matter experts, to understand what security means to them, and to put together a programme of work that addresses their combined individual success criteria. Over time the detailed scope was developed, refined, agreed, and delivered.
Being able to work with ambiguity is not the same thing as being tolerant of scope-creep. The project manager always needs to know the scope, needs to manage within that scope, and must adapt in the light of new information or circumstances.
The Agile Manifesto favours “responding to change over following a plan”. Now, this statement is guaranteed to upset most project managers, especially those whose lives revolve around MS Project. But actually the statement is correct. Is it better to deliver the wrong thing well, or the right thing badly? Best of all would be to deliver the right thing well, of course!
The Seven Essentials links Scope with Quality, because each deliverable defined in the scope should have associated with it some quality parameters, i.e. acceptance criteria. Prince2 is particularly strong on this discipline – building the plan around the definition of deliverables (“products” in Prince2-speak) and their quality criteria. This is a great approach, but beware being too rigid too early in the project.
Why do we need quality criteria? I have recently been reading about the history of the First Transatlantic Telegraph Cable. What a great project! Unfortunately there was a quality criterion missing. After several failed attempts, the first working cable went live on August 16, 1858 – with much public ceremony and celebration. Sadly the cable deteriorated rapidly over the following days with insulation breaking down, and it failed completely within the month. If you had been the project manager, would you have claimed success for laying the cable, or would you have taken the blame for its failure?
So, in summary, when I’m reviewing a project and considering the Second Essential, here is what I’m looking for:
- Is the scope defined and agreed with senior stakeholders?
- Do the deliverables have defined quality criteria?
- Is appropriate change control in place, and is it working?