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

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

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.

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

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