Every kind of project faces changes. During a kitchen remodel, the customers might change their minds about appliances, or a certain type of window might be unavailable. During a software development project, the competition might release a product with some exciting new features, forcing the development team to add these features as well. The specific change management process you follow should fit the size and complexity of your project; you will need to pay special attention to the number and diversity of your stakeholders. But every change process is based on the same fundamental model.

The Change Management Process

There are two parts to the change management process: the steps leading up to the initial approval of a product and the process for controlling changes to that product. Once the stakeholders accept a product, it becomes “controlled” and any subsequent changes must pass through the change management process.

Change management planning.

Establishing how the process of change will take place—occurs during the project definition stage. You will need to select the members of the change board and decide how often meetings will be held.

The intermediate products that will be subject to change management need to be identified and a configuration management structure created. (Configuration management means controlling the different versions of the product. It is explained in this article.) Below is a description of the basic components common to every change management process:

Identification of deliverables.

Identify all the project deliverables that will be subject to change management. The list will include everything that all stakeholders must approve, including requirements descriptions, design documents, and, of course, the statement of work.

Creation of the intermediate deliverables.

The project manager and team develop these intermediate deliverables as they execute the project. As each of these deliverables is created, it becomes a candidate for stakeholder approval.

Stakeholder evaluation/modification.

Once the product is created, various stakeholders will evaluate it and may request modifications. This step, along with continued development of the product, is
repeated until the appropriate stakeholders are satisfied with the documents.

Formal acceptance.

Stakeholders formally accept the product, producing a record of who approved the product and the approval date. At this point, the record becomes a control document; it is now a basis for action and project team members win begin to execute the decisions represented by the product. These approved products are now subject to configuration management.

The recording of change requests.

As ideas for change come in from the stakeholders, a designated team member records all change requests in a change log, noting their source, the date, and a description of the change. Each change request have a unique identifier, usually a number, so that it can be tracked and referenced.

Evaluation of requests and recommendation.

On a regular basis, the project manager or a designated team member will evaluate all potential changes for their impact on cost, schedule, and product quality, and make a recommendation to accept or reject the change. Both the evaluation and the recommendation are recorded in the change log.

Ongoing stakeholder evaluation modification.

Stakeholders consider the proposed change to the control documents and the recommendation from  the project manager. There are three possible outcomes to this evaluation:

  1. The change is accepted as recommended or with minor modifications;
  2. if the request has merit, but the decision maker(s) need(s) additional information, the request may be sent back to the project team with specific questions (this step may be repeated until the request is accepted or denied);
  3. the request is denied and the reasons for denial are recorded in the change log.

No matter what the outcome, the status of the request is updated in the change log and the originator is notified of the result.

Formal acceptance.

When stakeholders formally accept the change, this acceptance will be recorded in the change log, including who approved the change, the date of the approval, and the impact. The change may also produce an update to the project plan in the form of added, changed, or deleted activities. If the change affects a control document, the document is updated and the new version becomes tho basis for action.

Change Thresholds and Change Boards

While everyone admits the value of change management we also want to avoid any drag it might add to decision making. Including all stakeholders in every decision just isn’t necessary. Therefore, to balance the need for change management against the desire for flexibility and quick decisions, the project manager needs to separate changes into different categories, depending on how deeply they affect the project.

These categories are called change thresholds and are listed as follows:

The lowest threshold is for changes that the project team can approve.

These changes typically don’t affect the cost, the project schedule, or the way in which the customer will use the product. However, they can include design changes that make the product work better or last longer. Even though the team or project manager has the authority to approve these changes, they will still need to be documented.

The second threshold, which involves changes that will affect cost, schedule, or functionality, requires more formal approval.

This is the domain of the change board. Change boards meet on a regularly scheduled basis and consist of people representing the views of all stakeholders.

Even though a change board may be authorized to approve cost and schedule changes, it is usually for a limited amount only.

Above that designated amount, higher-level executives from the customer and project organizations must be involved. This is because these changes are usually large enough to threaten the business case for the project, fundamentally altering its profitability and market value.

Let’s look more closely at who makes up a change board:

  1. Representatives from the project team. These representatives offer the most expertise on the proposed change to the product and its effect on cost, schedule, and functionality. Though the project manager often plays this role, it is also appropriate for other team members to represent the project team.
  2. The customer’s representative. This board member must not only approve changes to the cost and schedule, but must also understand how the change affects the product’s usefulness.
  3. Representatives from groups with related products. For instance, the change board for a redesign of a truck fender may include engineers responsible for other parts of the truck’s cab. They will want to identify any changes that might alter the way their parts work.
  4. Representatives from functional management. Management participates on change boards to represent company policy. If the project team for the fender redesign should recommend a change that would result in using a new vendor, the company’s procurement representatives would have a say in this decision.

The larger the project, the more change management thresholds will exist—along with more change boards. Large programs have change boards operating at many levels. While this adds complexity, it is an appropriate strategy for controlling project decisions and pushing decision-making authority down as far as possible.

Don’t Let the Change Management Process Be Subverted

Stakeholders make decisions throughout the project. They choose the size, speed, color, and strength of the product. They agree on the cost-schedule—quality equilibrium. They divide the work and accept responsibilities. But the fastest way for a project to degenerate into a confusing mass of expensive rework is to allow these decisions to be changed randomly and without record.

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.

SHARE
Profile photo of Alex Puscasu
I am a Project Management practitioner with more than 5 years experience in hardware and software implementation projects. Also a bit of a geek and a great WordPress enthusiast. I hope you enjoy the content, and I encourage you to share your knowledge with the world.

LEAVE A REPLY

Please enter your comment!
Please enter your name here