Sample Chapter - ScopeThe following is a sample chapter from the book Simple Project Management. Note the step-by-step directions at the end that make it easier to apply the knowledge to projects. For an brief introduction to the power of this chapter, see Managing project managers
Scope - Set limitsScope is the line that separates what you agree to do from what you agree not to do. It becomes the foundation upon which all project effort is based. All cost estimates, schedules, and staffing decisions are based on it. Disagreements on scope destroy customer satisfaction and undermine team effectiveness.
The first rule in defining scope is to write it down. Only rarely is it possible to assure a common understanding of scope without putting it in writing. Describe the scope in terms that are meaningful to the team and to the customer. Clarity is more important than length.
Practice and experience will improve your ability to write a clear scope quickly. It helps to have someone review your draft scope. (If at all possible I like to distribute a bad draft early for comments. A bad draft is a powerful tool for helping to create a consensus.)
One scope description I reviewed did not make a clear distinction between what might be available in the future and what would be provided by the project. In another, I found that many necessary features where implied but not explicitly identified. When I brought this to the analysts' attention they showed me the prior draft that the customer had rejected as too expensive to implement. When I compared both drafts I found they were really describing the same scope. They had reduced the features that were explicitly described, but they had not really reduced the scope.
Make sure that everyone understands the difference between changing a draft of the scope and changing the scope after people have begun to rely on it. Changing a draft is cheap. Changing what people are relying on can be expensive in money and effort. Because of this the scope definition should be approved for use before anyone is allowed to rely on it. In fact, the act of approving scope is best understood as a decision that people can begin to rely on the scope definition.
Any proposed changes to the approved scope must be evaluated and perhaps rejected. The project manager may delegate this decision, but must keep a handle on it. Any accepted changes must be communicated to everyone affected so they can back up and redo their work as necessary. Repeated changes can be very expensive and damaging to morale. Because of this, sometimes, it is better to stay on track even if later you come up with a better idea.
Watch for any differences in interpretation of scope. Treat them as if they were changes to the scope (because that is what they will be to at least one of the parties) and evaluate their impact. Change the scope description to capture the new shared understanding. Communicate the clarifications to everyone affected so they can do the necessary rework. Reinforce the idea that everyone is responsible for establishing a common understanding of scope. Failure to do so is everyone's failure.
At the beginning of every project there is an original intention that includes, at least, what benefits are expected from doing the project. It may also include expectations of the time frame for completion, the general approach to be taken, and anticipated costs. Sometimes the scope develops in a direction that is significantly different than the original intention. If this happens make sure the project initiators agree with the new direction.
- Write down the project scope.
- Help the team to make the transition from "draft" to "relied-on" scope.
- Evaluate any proposed changes to the relied-on scope.
- Communicate approved changes to everyone who is affected.
- Treat any differences in interpretation of scope as proposed changes to scope.
- Make sure the project initiators agree with any significant changes in direction.