5 Steps to Sighting In Precise Project Scope
Accurate Scope - photo by bk1bennett via Flickr
When you come to initiating a project, determining the project scope can at the outset seem like an easy thing to do. After all everyone must be clear on what the project is delivering because otherwise there wouldn’t be project, right?
Sadly no. Accurately determining the scope of a project is one of the hardest tasks in initiating a Project. It may not seem so at the time. In fact at first glance it appears to be simplicity itself. However beware. Get this wrong or leave any possibility for “interpretation” and you will be well on the way to a flood of Change Requests and then the dreaded Project Failure.
Now many Project Managers think that the more vague they detail the project scope as, the better. Firstly it stops all the arguments with project stakeholders over scope and allows the project to actually get started. After all, at the initiation stage it is usually still unclear what the project is able to deliver, because requirements haven’t been documented yet. But the problem is that by doing this you are simply storing up numerous problems for the future.
For example, well meaning business stakeholders have a knack for changing their minds once the project initiates. By that I mean they keep demanding you deliver more functionality, but of course for the same budget and to the same timeframe. Unfortunately since the scope of the Project is vague, it’s virtually impossible for the Project Manager to insist that deliverables for the project have changed. It then becomes an uphill battle to fight against the constant scope creep.
To stop you getting into that position there are 5 steps you should follow. These are:
1. Insist on proper Business Stakeholder input from Day 1. Yes they will kick and scream but if the project doesn’t deliver, it’s your reputation on the line.
2. Ask the Business Stakeholders to tell you what they think the Project is delivering. Do this individually as it will make it clear where the differences of opinion are.
3. Once you have the high level information, move down into the detail of the deliverables. At this stage get the input of the Business Analysts and Development Teams so you can quickly clarify what is achievable in the timeframe.
4. Remember that what is Out of Scope for the project is possibly even more important than what is In Scope. So don’t overlook it.
5. When you have completed detailing the project scope, remember to pass it by the Business Stakeholders first, for their comments and feedback. Once you have their buy in, your project stands a good chance of delivering.
Of course there is much, much more, but at a high level following these steps will give you a chance of not falling at the first obstacle.
my-project-management-expert.com provides additional tips on how to complete the vital Project Scope Statement and deliver this by writing a Project Scope Statement in a Project Initiation Document. You will also find much more useful information there on how to deal with the whole complex area of Project Scope and ensure it doesn’t overwhelm your project or cause it to fail.
Jun 15th, 2009 at 2:39 pm
Susan,
Good stuff. One approach is to conduct a Product Development Kaizen, in which all the stakeholders are engaged in a sessiion of developing the project scope. The PDK is a structure approach, using tools (MindJet or some form of Mind Mapping) is common in many domains.
The critical success factor is to build the Work Breakdown Structure during this session. The WBS defines the project scope in terms of products and deliverables. By focusing on deliverables, the relationships between these deliverables can be discovered. The process is iterative and incremental.
But all the participants must be in the same room, guided by a facilitator. Google can find the “product development kaizen” materials.
The key here is have ONLY the inscope products and services in the WBS. Wasting time on what’s not in scope diverts the team fro, defining what “done” looks like. “Done” can then be the basis of measuring “Physical Percent Complete” (P%C), in unots meaningful to the stakeholders and the project team.
Only then can they say “we know what done looks like.” A WBS Dictionary is required on large federal contracts. This defines in deliverable terms what the result of the work is.
This provides the seperation between OUTPUT and OUTCOMES. It’s the Outcocmes you want.
Reply
Jun 15th, 2009 at 8:41 pm
I’d like to add that not all stakeholders are created equal. Some you can sit down and have a discussion about what they see the scope to be, and create the boundaries on the fly with them.
Others I’ve worked with just don’t think this way. They would rather see you generate a list of what you feel the deliverables should be, and send them a spreadsheet so they can scrutinize it themselves.
I was once in a session where we had a list of deliverables documented, and the stakeholder totally resisted even talking about them in a live discussion.
I don’t know if this is just a personality type thing, but in the latter case the only thing that I’ve found to work is the more formal exchange of spreadsheets until you gain agreement.
Reply
Jun 15th, 2009 at 11:07 pm
Josh,
The approach used in many domains is to start with a Concept of Operations (ConOps). This is a description of the systems behaviour independent from the technical requirements. This is a relatively stable document. For example the ConOps for the Hubble Robotic Servicing Mission was:
1. Do no harm to the telescope
2. Replace the wide field camera
3. Install the external battery connections
There were a few more “concepts,” but that was basically it.
Then the requirements were derived from their. This allows the requirements to have a “reason” for being there. The ConOps answers “why” we want the system.
Next the requirements are developed in a layered manner Tier 1, 2, and 3. Each of these has a Measure of Effectiveness (MOE) and a Measure of Performance (MOP). This allows the stakholder to see what “done” looks like in units of measure meaningful to them.
This heirarchy of information MUST be in a well formed tree. This is the core paradigm of Systems Engineering. Connections between requirements are dependencies and should be minimized.
Using a software paradigm, this minimizes coupling and maximizes cohesion.
Reply
Jun 16th, 2009 at 5:14 am
I’m seeing an awful lot of discussions of “scope” that seem to ignore several critical aspects of the topic:
1. The role of the project life-cycle. Glen’s second post is absolutely on target even though he doesn’t explicitly call out project life-cycle phases. With most projects, it is impossible to define the scope precisely at the beginning. Whether you call the first phase “concept of operations” or “conceptual development” or “preliminary requirements,” there is preliminary work that needs to be done, and done in a disciplined, thoughtful manner. I think one of the main reasons for this (especially in software and IT) is that PMI and its followers have confused the project life-cycle with the project management process groups. Even agile development projects have a disciplined, life-cycle-like approach within each iteration.
2. A definition of scope. What exactly is scope? The dictionary says “boundaries,” but we need a definition of what will be used to identify boundaries. My definition (the one I originally developed for the 1996 PMBOK Guide but have since modified somewhat), is that scope is the characteristics of the product of the project. The business user will not be able to provide anything other than an initial definition of scope, and that preliminary definition is called “requirements” as Glen so ably illustrates with his Hubble example. The requirements are used to develop a design, and the design now represents a new understanding of scope. This process of regular updates to the scope continues throughout the project life-cycle.
3. Changes to scope are good … as long as everyone understands that such changes may cost more money and take more time. The original article suggests that good scope definition will eliminate change requests. Wrong! That belief will drive the project manager to an early grave. Changes will always happen no matter how much front end effort you put into the project.
Duncan
Reply
Jun 16th, 2009 at 2:53 pm
Hi Everyone,
Thanks for reading the article and for taking the time to respond. Its great when a blog post starts a debate!
To answer your queries:
Glen – The process you outlined is often used in Six Sigma Projects which specifically use WBS. This is definitely a valid approach, however in my experience this is mainly utilised within the Defence, Engineering and public sectors rather than in very fast moving IT projects. However that isn’t to say I haven’t utilised elements into projects I have run particularly the JAD process which is very similar to Kaizen approach you’ve outlined.
Duncan – Yes you are right to say that detailed scope cannot be determined until later on in the project lifecycle. In fact I would go so far as to say that this is the case until the BRS and detailed requirements are approved.
However I would completely disagree with your comments regarding the fact that a Business User would only have an initial definition of scope. This really depends on how much User and Product Research has been done upfront. For example on a previous project the Business had spent a year developing the product based on focus groups. They therefore had an extremely clear idea on what they required the project to deliver.
I would also totally disagree with point 3 that you made. Scope changes are in my view not good and few Project Sponsors understand that what they might perceive as being a small scope change in fact could drammatically increase budget and timeframes no matter how you try to explain it. Further in my projects not hitting the original launch date is not an option, as there are usually huge advertising campaigns or statements to the Financial Markets which are dependent on their delivery.
Lastly whilst a detailed scope statement does not guarantee no Change Requests it at least gives the Project Manager a way to reject them. If the initial scope defined is vague this is much harder to do gracefully in the face of determined Sponsors who want their cake and to eat it too! Of course at the end of the day it is up to the Project Manager stand up for their project budget / timeframes and if they don’t do this then no matter how detailed the scope statement is, this will not help.
However from my perspective I prefer to make life as easy for myself in what is normally an extremely challenging project to deliver in terms of timeframes, scope, resources and budget. A clear understanding of initial scope is, I’ve found, a good way to achieve this and it has mean’t that on the multi million $ projects I’ve delivered, the numbers of Change Requests on each can be counted on one hand.
Regards
Susan
Reply
Bill Duncan Reply:
June 21st, 2009 at 6:27 am
Susan –
We may be drawing our boundaries differently. For example, the year’s worth of effort that you describe above is part of the project. It appears to me that you are looking at a subproject in much the same way that a “construction project” is only a phase of a larger “facility development project.” In my view, your Business User spent a year working to develop a better understanding of scope. You then became the beneficiary of all that work.
Re your comment that “few Project Sponsors understand that what they might perceive as being a small scope change in fact could drammatically increase budget and timeframes.” In essence, you are accusing your sponsors of being too stupid to understand your explanation. The keys here are to make sure that sponsors realize that (a) requirements are not scope, and (b) they pay for the time and cost of the work to implement the scope change.
Why reject scope changes? If the sponsor is willing to pay or extend the deadline, that is the RIGHT thing to do.
Duncan
Reply
Jun 17th, 2009 at 11:39 am
Susan and Bill,
Let me clarify a few things. The Identification of Capabilities comes before Requirements elicitation in our domain. The 3 Hubble statements are statements of Capabilities, not specification requirements. The robot must possess the “capability” to change the wide field camera. The technical, operational, safety and mission assurance requirements were then derived from this needed capability.
Jeffery O. Grady’s series of Systems Engineering books is the best place to look for general information on the differences between Capabilities and Requirements. There is a long history of poor advice on requirement elicitation that Grady puts back into order.
The boundaries of the project are defined by the Concept of Operations (ConOps). But the ConOps is not a requirements specification in the traditional sense. The ConOps states what the system must be “capable” of doing when it is complete. It is then incumbent on the requirements elicitation process to identify what requirements must be fulfilled to enable the ConOps to be fulfilled.
So to review Capabilities > Requirements > Design > Build/Test iterations > Fly. Without the Capabilities defined in the ConOps requirements creep (scope creep) is unavoidable, because you cannot ask and answer “why are we doing this?” “How does this requirements support the mission to repair HST?”
Susan
The WBS is a commonly mis-used and mal-used tool. The current MIL-STD-881A dictates the WBS to be a breakdown of the work elements needed to construct the product and collect the cost for each of those activities. The current practice we employee with our IT clients is the plan the program to the Work Package level. The WP produces a single (if at all possible) outcome for the IT project. The parent / child relationships between these WP’s are essentially the WBS. Only product outcomes are in the WBS.
Fixing scope is a double edged sword. The primary scope of a manned spaceflight program we work – which has extensive software elements has undergone 3 major changes in the past 4 years. Scope change is mandatory if the project is non-trivial. External influences, mission changes, technology changes all drive scope change. “Managing in the presence of change,” is the challenge for the project or program manager.
“Managing in the presence of change” in an IT environment is greatly enhance with the use of Agile development methods.
Reply
Jul 13th, 2009 at 4:41 am
Hi All,
I have really enjoyed the discussions above and wanted to say thank you to all of you for the fine experiences shared above. The various comments reveal some of the critical issues in project management that young PMs like us are looking for.
And thanks to Josh for publishing Susan’s blog that led to these enriching discussions.
Regards,
Paul
Reply