Scope Pattern

Is this a WikiSquatting advertisement? Candidate for deletion? If we just delete the copyright notice and the link, should it stay?

The copyright on the original is mentioned so that anyone who recognizes this material as coming from the book will know that the author put it here with the full expectation that it will be changed by anyone who wishes. Also, some people might be interested in seeing how much it has changed.

ProjectManagementPatterns says that this section contains "Patterns that capture forces and resolutions of forces in managing a project." All projects must deal with the forces surrounding scope. For example:

There are forces that expand and contract scope - people wanting to do more vs. people who want a project that can be finished. The manager resolves that by defining the scope and writing it down.
There are forces that cause the project scope to change over time - new ideas and changing circumstances. The manager resolves these through education ("people are relying on this, they will have to do re-work if it changes") and making sure all changes are evaluated.
There are forces that try to take the project in new directions vs. those that try to keep it pointed towards the original goal. The manager resolves these by always going back to the originators and either getting their buy in that the new direction is better or bringing the project team back on track.

How is this WikiSquatting? Isn't this site trying to explore patterns that identify the forces and the resolution of forces in project management? I would have thought that the resolution of the forces surrounding scope would be comparable to the pattern "Main Entrance" in architecture. While these aren't programming patterns they are patterns for the context in which most programming is done.

Scope Pattern - Set limits

Scope 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 order to make the transition explicit, most groups have a small ceremony called "signing off" on the scope. Typically, both the technical lead and the business owner should sign or approve a particular version of the scope document, and it is understood that only after the scope has been "signed off" can people begin to rely on the scope definition.

Any proposed changes to the approved scope should 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.

Scope volitility is often limited by requiring a formal "change request". In an ideal environment, a change request is submitted when new requirements surface. The developers review the request and estimate how it will impact the schedule, then the request is either approved or rejected. So long as the changes are few in number and the schedule is actually changed when scope is extended, this process can work well. But if the changes are frequent enough then a completely different approach may work better (see ExtremeProgramming).

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.

Scope Pattern in Summary:

Write down the project scope.
Use "signing off" to hilight 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.

This page started as a sample chapter from the following book:

Simple Project Management: What Everyone in Your Organization Needs to Know About Project Management

The original is Copyright 2004 by Brian Christensen. This version was posted here by the author with the understanding that anyone may make any changes they wish. The original can be found at: http://www.SimpleProjectManagement.com/service/book.scope.html

See: SimpleProjectManagement

More information on project management patterns is available at: http://www.SimpleProjectManagement.com/think/patterns.html

ProjectManagementPatterns