How to Control Changes to The Project

How to Control Changes to The Project (#5 in the series How to Control a Project)
By Michael D. Taylor

Changes to the project management plan are inevitable. Rarely does a project manager finish a project with the same project management plan established at the Final Planning Review. If a project manager does not have a formal process for reviewing, evaluating, and approving any such changes the resulting impact will be uncontrolled scope creep.

Why Control Changes?

Uncontrolled changes will create confusion, and confusion will erode commitment to the project. Product quality, overall morale and general loss of interest will most likely take place when a project manager cannot control changes to the project management plan. The project manager’s upward spiral in career advancement may also be dampened when key stakeholders see ineptness in managing project changes. If changes are not managed properly the project manager will experience unacceptable schedule slips, significant cost overruns, and reduced product quality.

Typical Change Sources

Typical project change sources may be generated by any of the following:

• Late clarification of requirements
• Continual product feature enhancements
• Corrections to poor planning
• Things the customer forgot when planning
• Changes in corporate strategies
• Corrections to product design deficiencies
• Arrival of new technologies

Configuration Management

The process for reviewing all change requests, approving changes and managing changes to the deliverables, organizational process assets, project documents and the project management plan is called “Perform Integrated Change Control.” This is also sometimes called Configuration Management.

Integrated Change Control

Integrated change control is usually comprised of three main elements. First is the project baseline which is based on the project management plan. This is the project manager’s reference point, much like a compass providing direction. Next is the change control board which reviews, evaluates, and either approves or rejects proposed changes. Finally, the configuration status accounting aspect, also called “change tracking,” processes any approved changes. If a change to any portion of the project management plan is approved it is critical that all project members be made aware of it. Since this can entail a significant amount of work some project managers will appoint a configuration management specialist to process and track all approved changes

Change Control Board Members

Even though there may be those who regularly participate on the change control board project managers should feel free to include others as needed. After all aspects of a proposed change are discussed and evaluated the project manager ultimately makes the final decision. In some projects the CCB is external to the project. Prudent project managers will include either the customer or a marketing representative on the CCB so that the customer’s view of the potential change is taken into account.
Typical CCB participants may include the following:

• Project manager
• Change originator
• Systems experts (systems engineers, chief architects, chief chemists, etc.)
• Those who will impacted by the change
• Configuration manager
• Others as needed

Change Assessment

When a proposed change is presented to the CCB the project manager will be faced with a series of important questions needed to assess it. These may include the following:

• What are the benefits of the change?
• Does it satisfy a customer/user’s need in a better way?
• Will it impact any other activities?
• How will it affect the project’s cost?
• Will it require additional project funding?
• How will it affect the project’s schedule?
• Will it require an extension to the project completion date?
• How will it affect the product’s quality?
• Can it be deferred to the next product version?

Configuration Status Accounting

Once a proposed change has been reviewed by the CCB, and the project manager has decided to accept the change, it must be disseminated to all project members. For example, if a change to the project schedule has been approved the revised schedule must be announced and provided to everyone on the project. Nothing is more confusing on a project than when multiple versions of a given documents are inadvertently being followed. Configuration status accounting, or change tracking can be very time consuming so some project managers will assign this task to a configuration manager, or to the project coordinator.

This individual will record and document all approved changes to provide what is sometimes called an audit trail. This may be needed if a question arises in the future about project changes. The configuration manager will also post the change on the project’s Intranet so that it is available to all, and make certain that everyone on the project becomes aware of the approved change. If any contract fees are affected these are to be tracked as well.

Typical previously approved project documents that may fall under the jurisdiction under CCB may include the following:

• Customer/user requirements
• Design disclosure documentation
• Engineering drawings
• Specifications
• Software architecture
• Product interfaces
• User interfaces
• Source code
• Final test plan

Change Control Process

The change control process begins with a change proposal conceived by project members, project customers, or anyone external to the project. Some initial screening may be required to ensure that all necessary information about the change is complete and ready to be presented to the CCB. This eliminates many “false starts” in a CCB meeting.

Next, the CCB reviews the proposed change and the project manager either rejects or accepts it. If it is deemed favorable to the project manager the impact of the change to the project budget and the project schedule must be assessed. If the change can be absorbed within the existing project budget, and it will not affect the project completion date, it is sometimes categorized as a Class II change and does not require formal approval by the key stakeholders. However, if it will impact the project budget, or the project completion date, it is often categorized as a Class I change and requires approval by the key stakeholders.

If the key stakeholders approve the change then it implemented and the project management plan is updated. As stated previously, the approved change is then disseminated to all project participants. The figure below illustrates this change control process.

Integrated Change Control Flow Chart

MICHAEL D. TAYLOR, M.S. in systems management, B.S. in electrical engineering, has more than 30 years of project, outsourcing, and engineering experience. He is principal of Systems Management Services, and has conducted project management training at the University of California, Santa Cruz Extension in their PPM Certificate program for over 13 years, and at companies such as Sun Microsystems, GTE, Siemens, TRW, Loral, Santa Clara Valley Water District, and Inprise. He also taught courses in the UCSC Extension Leadership and Management Program (LAMP), and was a guest speaker at the 2001 Santa Cruz Technology Symposium. His website is www.projectmgt.com.