Jag Venugopal's Blog

June 24, 2009

Scope Management Through The Project Lifecycle

Filed under: Project Management — Jag @ 6:16 pm

As far back as 1987, poor scope management was recognized as a principal reason why projects failed (Wawruck, 1987). Nevertheless, scope management continues to occur as a factor in project failure (e.g. see Google(1)).  Even prominent authors (e.g. see Wysocki, 2007) regard scope (or change) management as primarily a process of filling in a change management form and a project impact statement form.

 In this article, I discuss the following key components of a scope management process. I also highlight the points during the project lifecycle in which scope management comes into play.

  • Setting expectations on scope management
  • Identifying how a change in scope is detected
  • Quantifying changes in scope
  • Documenting changes in scope
  • Approving changes in scope
  • Implementing changes in scope

 Setting expectations on scope management

 Novice project teams start managing scope when they notice that the user has requested a feature which does not appear to be in the original project scope. The project manager starts quoting the requirements document to the client in the hopes of obtaining agreement that the feature being requested represents a change in scope. The client, more often than not, sees the feature request as merely an elaboration, or something that was always intended. They balk at acknowledging it as a change, much less pay for it or accept a schedule slip. Such discussions are almost never pleasant, and end in a compromise solution that can leave both the client and project team feeling that they caved in to the other party.

 The best time to set expectations on scope management is at project inception, when the project charter and statement of work are being discussed. At this point, the project team needs to reach agreement with the client on how scope will be managed. The client needs to understand that changes to scope have a cost associated with them, that will need to be managed, and that the farther one goes down the project, the greater the cost of a scope change. The project manager can have better buy-in from the client on scope management if they can demonstrate to the client that proper scope management is part of the project methodology, and can reduce their risk of not hitting schedule and cost milestones on the project.

 At project inception, the project manager has been successful in scope management if they get buy-in from the client on:

  • The desirability of a scope management plan, with the understanding that it is being put in place to help the project succeed.
  • A budget for unanticipated scope changes that will nevertheless occur as better knowledge of the system is developed.
  • Establishment of a change control board to review and approve or reject scope changes. Such a change control board would have, among others, the project sponsor, the client project manager and the consultant project manager as its members. Various client line managers that are impacted by the project may also participate in this board.
  • Agreement that project scope is determined by the signed-off project requirements.

 Requirements  Gathering Phase

 Because project scope is not yet defined during the requirements phase (other than probably high level scope boundaries), this phase is naturally open-ended. When consultancies agree to execute the requirements phase on a firm-fixed-price basis, it can lead to unnecessary tension between the client and the project team. The client is interested in fully elaborating project scope, so that changes do not have to be made in downstream phases. They are still trying to figure out exactly what they want, and are looking for discussions and consultation to help firm up their mind. The consulting organization, on the other hand, has a certain timeframe in which they need to get their requirements phase completed and the project transitioned to the next phase. 

 I worked for a high-flying consultancy in the ’90s that quoted fixed-prices for requirements phases. This had the unfortunate effect that when the time allotted for the phase was complete, the phase was declared to be over, even if the requirements were not properly elaborated. Another particularly vicious practice at this (publicly traded) consultancy was to ensure that requirements phases never crossed quarter boundaries. The phase would be terminated early if it became apparent that it would drag into the next fiscal quarter, thus not allowing for revenue to be recognized in a timely manner. Such shenanigans on requirements invariably meant poor requirements, leading to multiple scope changes during development, leading to the team falling further behind on a fixed-price development, leading to further corners being cut. In other words, a vicious cycle of scope changes that was difficult to get out of.

 Recognizing Scope Changes

During the requirements phase, it is difficult, perhaps inappropriate even to control scope. This is because scope is still being elaborated. Thus, a time and materials approach for the requirements phase allows both the client and the project team to discuss project scope fully, without any extraneous considerations getting in the way.

One way to ensure that the requirements phase is not open-ended is to divide it into two sub-phases:

  • Scoping: During the scoping sub-phase, a list of features/use cases is created, without necessarily elaborating it to a detailed level. For each such feature or use case, a determination is made on whether it needs to be implemented in the current project (phase) or in a future project (phase).
  • Requirements elaboration: The use cases or features identified in the catalog for the current project are elaborated

 Key to detecting scope changes downstream of the requirements phase is to have the business requirements signed-off, and therefore, baselined. As part of the sign-off process, the client must clearly understand the implications of their sign-off for future scope changes. Ideally this would have been discussed and completely understood at project inception itself. If the requirements are not signed-off and baselined, it is virtually impossible to argue that any change in a downstream phase is a change in scope.

 Quantifying Scope Changes

 Changes in scope have the ability to impact virtually all downstream deliverables of the project. Some examples of the impact of scope changes are:

  • Changes to the requirements document, re-baseline with signoff
  • Changes to software design
  • Changes to software already developed
  • Changes to test cases and test data
  • Changes to application help and user manuals
  • Changes to the deployment plan
  • Changes to the training plan
  • Changes to the end-user communication plan

 For each of these areas, the additional tasks and the effort hours will need to be identified. A revised what-if project plan will need to be prepared with these impacts taken into account. The project plan should reflect schedule and cost changes as a result of the scope change.

 Documenting Scope Changes

 Once all the preparatory work discussed in the prior sections has been completed, creating a scope change document is straightforward. There are many templates available, most of which are adequate to do the job. The template should contain the following fields:

  • Change request number and title
  • Business-domain description of the proposed change, and the rationale for it
  • Any potential workarounds that would obviate the change
  • Details of impact of the change on various areas (as discussed in the section titled Quantifying Scope Changes)
  • Schedule and cost impact of the change
  • Approvals
  • Supporting documents (e.g. the proposed new project plan, wireframes if available, etc)

 Approving and Implementing Scope Changes

 With all the work that has gone into both the scope change process and the scope change request itself, the process of approving and implementing the changes should be straightforward.

 Depending on immediacy and impact, scope changes can either be reviewed during the next or change control board meeting, or one can be specially convened to discuss the change. During this meeting, a decision is made to either approve the change, reject it, or send it back to the drawing board.

 Once a change has been approved, the updated documents (project plan, requirements, design, etc.) are re-baselined. The tasks pertaining to the change have now been entered in the project plan, and are treated similarly to other project tasks.

 Special Considerations

 Cost of Analyzing Changes:  For some change requests, it takes time (and therefore money) to understand the proposed change, document its impact, and then discuss it before the change control board. Analyzing such a change will have a cost and schedule impact, even if the change is ultimately rejected. The ways to deal with such changes are:

  • Discuss up-front with the client the costs of analyzing the change and obtain approval to proceed with analysis
  • Absorb the cost — especially on a large project with infrequent changes, where the probability of the change being approved is high. The cost of analyzing the change then is simply the cost of sales. Clearly this can’t be done beyond a point, but there is some value in not appearing as a nickel-and-diming consultancy.

 Small and Frequent Changes: For some changes whose impact is relatively small, the overhead of an elaborate change management process may seem to be too much. One potential way to address this would be to establish a cost/schedule “bank”, against which such changes would automatically be counted, if approved by the client project manager. Eventually when this bank is depleted, a request will be made to the change control board to replenish the bank.


Wawruck, Walter (1987). Scope Management – Important But Neglected. Retrieved June 24, 2009, from Expert Project Management by Max Wideman Web site: http://www.maxwideman.com/guests/scope/management.htm

 Google Search for Poor Scope Management(1). Retrieved June 24, 2009, from Google Web site: http://www.google.com/search?hl=en&q=poor+scope+management&aq=f&oq=&aqi=

 Wysocki, Robert K.. “Chapter 10 – Monitoring and Reporting Project Progress”. Effective Project Management: Traditional, Adaptive, Extreme, Fourth Edition. John Wiley & Sons. © 2007. Books24x7. <http://common.books24x7.com/book/id_17023/book.asp> (accessed June 24, 2009)


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: