Select Page

Categories

Project Scope Control – Part 2: Change Management (#2 in the series Project Scope Control)
By Samuel T. Brown, III, PMP, Global Knowledge Course Director and Instructor

This article continues from the discussion of defining and setting boundaries for scope in Part 1.

Reliability of Change Management

The rationale for project change control is straightforward. Change control provides a mechanism for identifying change, the impacts of change on critical elements of the project and explicit decisions regarding the change. Project change control primarily focuses on change impacts to the scope, schedule, and cost of the project, but also includes attention to the related impacts a change may have on other areas of the project like quality, risk, communications, team, and contracts. The intent of project change control is to make sure that changes are beneficial, not to prevent change.

The natural starting point for any sort of control of changes begins with specific and clear definition of what is expected and agreed, which is why the Work Breakdown Structure (WBS) is a critical input to scope change control. Performance reports are also an important input for change control because they provide a regular checkpoint between plans and reality, and, therefore, a regular opportunity to identify deviations, their causes, consequences, and any corrective actions necessary.

The outputs from scope change control include several items, the most notable of which may be adjustments to baselines. Project baselines are only adjusted in response to changes in project scope; that is, in response to changes in the amount of work agreed to be required within the definition of the project.

A change management plan provides a framework for managing changes within the project. The change management plan should be established very early in the project life cycle, essentially as the first direct step in establishing a change control process. A balanced approach is necessary, ensuring that the effort required to manage change is in proportion to the value and benefit of the project. Change management is, however, a critical success factor in project management and is not optional even in small, simple projects.

The change management plan and the change control process must be documented, communicated and enforced. Eric Verzuh makes the point clearly, “Don’t let the change management process be subverted.The formal change management process guards against this anarchy of sudden decision changes. Even though it adds bureaucracy and overhead to the project, it remains one of the project manager’s strongest tools both for self-preservation and for managing expectations.”

The change control process is the implementation of the change management plan and provides the step-by-step guidelines for requesting, recognizing, evaluating, deciding and responding to changes that affect the project. The change control process must define or enforce the appropriate use of the specific control documents required by the change management plan. At a minimum, the change control process must ensure the consistent use of the change request form, the change order form and the change-tracking log.

It is important that the change control process be as simple as possible. There is an inverse relationship between process complexity and probability of stakeholder compliance. A simple-to-understand, straightforward process has a much greater likelihood of being followed consistently by all stakeholders, particularly those on the project team.

The Project Manager is the central point of contact for all changes. The Project Manger acts at the primary receptor of change request and the primary overseer and enforcer of the change management process. Initial evaluation, determination of whether further analysis is warranted, assignment decisions, escalation decisions, and communication of change response decisions back to the requester and other affected stakeholders all fall within the sphere of the Project Manager’s responsibility for change management.
Riding the Rolling Wave

Finally, as we conclude our discussion, it is appropriate to revisit the PMBOK Guide® idea of progressive elaboration and it’s applicability to scope control. The PMBOK Guide® defines progressive elaboration as “Continually improving and detailing a plan as more detailed and specific information and more accurate estimates become available as the project progresses, and thereby producing more accurate and complete plans that result from the successive iterations of the planning process.”

The PMBOK Guide® then goes on to define Rolling Wave Planning as “A form of progressive elaboration planning where the work to be accomplished in the near term is planned in detail at a low level of the work breakdown structure, while the work far in the future is planned at a relatively high level of the work breakdown structure, but the detailed planning of the work to be performed within another one or two periods in the near future is done as work is being completed during the current period.” Rolling wave planning, then, is a planning technique that accepts the unknowns of the project horizon and consequently compensates by focusing detailing near-term plans through systematic and iterative attention as the project horizon is approached.

In his presentation to the 29th Annual Project Management Institute 1998 Seminars & Symposium, Gregory D. Githens identified rolling wave planning as most appropriate for “new product development, information systems and other technical development environments. [as] it balances structured process with flexibility. It is appropriate for project life cycle models that allow incremental development (spiral, evolutionary prototyping, etc.

Rolling wave planning does not eliminate the need for project initiation processes or activities; rather the technique is dependent on the essential project definitional artifacts like the project charter and preliminary scope statement. Rolling wave planning also relies on the development of a high quality WBS, albeit through successive cycles of planning and replanning. The process of rolling wave planning has been summarized as a seven-step process:

  1. Evaluate the development strategy.
  2. Develop time buckets. Time buckets require the establishment of criteria for planning horizons, including the number and duration for each horizon. Visible models, well articulated requirements, and stakeholder involvement are important supporting techniques.
  3. Develop high-level estimating, based on available knowledge and current assumptions for all time buckets.
  4. Detail WBS for first time bucket, including the subsequent activity definition, activity estimating, activity resource estimating, activity duration estimating, and cost estimating. Be sure to establish a work package date for iteratively planning the next time bucket.
  5. Complete risk analysis, establish contingency and management reserves, and baseline the current project plan.
  6. Execute the plan for the first time bucket.
  7. Close the first time bucket, including evaluation of lessons learned, and undertake replanning for the next time bucket. Continue to repeat the planning cycle from step 3.

Summary

Scope control is one of the fundamental processes defined in the PMBOK Guide®, and remains among the most challenging processes faced by practicing project managers. Establishing practical scope control requires constant attention to the three pillars of support; clarity of definition, precision of boundaries, and reliability of change management. Given the often complex nature of many projects of a technical or development nature, in which the entirety of requirements are unknown or indefinable in a detailed fashion, scope control can be enhanced through the use of planning techniques that provide structure for systematic progressive elaboration as ongoing project work reveals new details for use in the next near term planning cycle.

References

  • Guide to the Project Management Body of Knowledge, Third Edition, Project Management Institute, 2006.
  • Presentation by Gregory D. Githens, 29th Annual Project Management Institute 1998 Seminars & Symposium.
  • Verzuh, Eric. “The Fast Forward MBA in Project Management”, 1999, pg. 240.

® PMBOK and Project Management Body of Knowledge are registered trademarks of the Project Management Institute.

About the Author

Samuel Brown, PMP, is a course developer and instructor for Global Knowledge with 25 years experience teaching. In addition, he has provided project management consulting services for a variety of clients including GE, Glaxo Smith-Klein, Bristol-Myers Squibb, Michelin Tire, and IBM.

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge delivers comprehensive hands-on project management, business process, and professional skills training. Visit our online Knowledge Center at www.globalknowledge.com/business for free white papers, webinars, and more.

© Copyright 2008, Global Knowledge. All rights reserved.

Recommended PM App

Recommended PM App

Categories