The Project Management Institute is very keen on change control. It insists that, once your scope is baselined, any change requests need to be analysed fully and the consequences of the change appreciated before any decision is made.

On this page:

• Challenges in Implementing Effective Change Control
• Analyzing Change Requests and Stakeholder Involvement
• Planning for Change Control in Projects

Challenges in Implementing Effective Change Control

For a project manager, the important point with change requests is not to reject them out of hand but to present the requester with the consequences of the change and ask if they are willing to bear the costs. In general, the later in the day a change request arrives, the more expensive it will be.

For instance, if the foundations are laid and the customer suddenly decides that the windows should be slightly larger, the change involves revising the drawings and updating the order for windows. However, if the roof is on, changing the size of the wall openings, involves major surgery. Similarly if, in the course of building a new road, the construction workers uncover a nesting site of the polka-dotted woodpecker, having to reroute the road involves new environmental impact studies (in case other nests are discovered) and different compulsory purchase orders.

Anyone reading this will argue that these changes reflect poor planning in the first place. The building customer clearly was not sure of their requirements before committing and the original environmental impact assessment was obviously flawed. To prevent the need for changes, take care during the requirements gathering and scope definition.

Architects often build scale models of the proposed building, so that customers can visualize the finished product before serious money is spent. Similarly, software developers and lean manufacturers strive to build up a mutual understanding of the requirements with the customer, before committing too much to the product. Agile practitioners adhere to the principle: We have come to value customer collaboration over contract negotiation. The goal of the scope planning is neatly summed up by the Spice Girls: Tell me what you want, what you really, really want?

But no matter how well we plan, there is always the unknown issue that can come out and bite us. This is typical in research projects, where the proposed solution is untried and can prove to be spectacularly unsuccessful. For instance, an aerospace company might sponsor a project to improve jet engine performance, but the engineers discover some harmonic resonance that means the whole structure of the engine casing needs to be redesigned as well as the jet mechanism itself.

In other words, having a comprehensive scope planning exercise might not be sufficient to ward off change requests from the project. Not only can technical difficulties affect the project’s scope, business realities can also scupper the well-planned project. A typical example would be the launch of a competitor’s product. This might feature something that is proving extremely popular in the marketplace. Our product needs to respond to this or we are wasting our time competing.

Unfortunately, change control is often dismissed as being cumbersome and bureaucratic. Indeed, some project team members are reluctant to place artefacts under change control, because of the difficulty altering them after sign-off.  Change control board meetings might be scheduled at intervals that are too far apart to be responsive. Similarly, there might not be anyone assigned to analysing the change request quickly enough. As the project manager, you need to ensure that there is a mechanism in place where any stakeholder can make a change request. There also needs to be people trained in analysing these requests and there needs to be a reactive change control board who can decide quickly on whether to accept or reject the decision.

Analyzing Change Requests and Stakeholder Involvement

However, remember that the change control board needs to include the stakeholder who has raised the change request. The analysis of the request is effectively a feasibility study that aims to determine the consequences of the change in terms of deliverables, schedule, cost, quality and risk. It is really up to the requester to decide if the consequences are worth the additional benefits the change will confer.

In the real world though, while the requester might feel that the change should be made despite the consequences, s/he might not have the power to make the decision. For example, a team member might request a design change that will ultimately create a better product, but involves licensing third-party technology that doubles the unit price of the end result. In this case, the project sponsor may order the rejection of the change on cost grounds.

Planning for Change Control in Projects

At the end of the day, one of the important planning aspects of any project is how change control will work – how the requests are analysed (what factors are considered, how much time should be spent on them), who ultimately decides on accepting or rejecting (this will differ per project) and how long this process should take.

Even if we cannot plan change out of our projects, at least we can plan how to deal with change.