Managing Change in Projects

28 August, 2014

The project is the mechanism used by organizations to effect change. If we want to add a new product to our offerings, we develop it by chartering a new project. If we want to rebrand the company, a project is how we will do it. Ironically, one of the most frustrating things for a Project Manager is fielding change requests once the plans have been signed off and the work has commenced.

If many changes are expected on a project – for instance, if the requirements are not very clear at this point in time, Project Managers should consider iterative and incremental techniques, such as the wide range of agile methods available. This approach involves planning a small amount of work at a time, obtaining feedback on each bit done and allowing the overall picture to evolve with understanding.

However, there are certain types of project where such a course would not work. These are projects where planning permission must be sought or complicated sub-assemblies need to be created by third-parties. You cannot get planning permission to build a structure whose characteristics will evolve over time. Similarly, no company will take on a construction task unless it is clear what is required.

Unfortunately, the more detailed our plans, the more upsetting change is. The Project Management Institute has devoted an entire process to change control in its Guide to the Project Management Body of Knowledge (PMBOK® Guide). Perform Integrated Change Control is part of the Monitor and Control process group and explains what to do in the event of any change.

Software developers at this point are probably thinking of version control. This is where a snapshot of an emerging software product is archived at every significant stage. The purpose of version control is to allow the developer retreat to an earlier version if the current step is not working out. Software version control also allows stable versions of sub-systems to be identified and used for integration testing, while development proceeds on the components. On production systems, version control can allow customized versions to be supplied to particular customers.

However, what the Project Management Institute defines as change control is a different concept. In the Perform Integrated Change Control, the PMBOK® Guide defines two, related concepts: change control and configuration management. Change control relates solely to changes in scope, rather than to changes in specification. So, for instance, if we are developing a new food blender, tests might show that one of the attachments has poor wear characteristics. If we do not have time to re-engineer the attachment, we might decide to ship two such attachments with each blender.

In contrast, configuration management handles changes to the specification. For instance, if we are making a new executive jet, we might realize that a more powerful engine needs to be specified to yield the target performance figures. A confusing situation arises if we decide to add a new component to the specification – a new attachment to the blender, for instance. This could be considered both a change request and a configuration change.

No matter how you categorize the changes, the vital thing is that each proposed change is fully analysed to assess its impact. Ford probably took this analysis to extremes in the 1970’s when it discovered a badly positioned bolt in its new Pinto model. The location of the bolt meant that it could rupture the fuel tank in a rear-end collision. Ford’s accountants calculated the likely costs in terms of future law suits and decided that it was more cost-effective to ship the car as it was, rather than re-engineer the structure. Ford’s project managers clearly did not understand the concept of intangible benefits back then.

However, all changes have consequences. They might increase the unit cost of the product; they could cause the project to miss its planned end date and they might introduce additional risks to the project. On the other hand, a change might make the product more attractive in the marketplace, reduce production costs and even allow the product to meet new legislation. In other words, changes can result in better products, services and results and should not be regarded as inconvenient interruptions to a carefully planned project.

The main thing for a Project Manager to appreciate is the consequences of the change request. These consequences need to be articulated to the stakeholder who has suggested the change. The decision to introduce the change should be made based on full information – what are the consequences of introducing it and what are the consequences of not introducing it? This is why a Change Control Board is recommended – to assess change requests from a variety of perspectives.

If a change is accepted, the Project Manager needs to be aware of the Validate Scope process. This is where compliance with the planned scope is demonstrated. If the scope (or configuration) has changed, then the Requirements Traceability Matrix also needs to be updated. If clear acceptance criteria have been laid down by the customer, they need to review the change request as well and revise their criteria as appropriate.

At the end of the project, it is always useful to reflect on the volume and the nature of the change requests made during the course of the project. The Project Manager should wonder why so many change requests were made. Often this reflects a lack of understanding of what needed to be done. If this is the case, future projects need to spend more time on Project Scope Management. Indeed, many projects are kicked off with little understanding of what the finished product will be. In these cases, pre-project research and feasibility studies should have been done prior to project charter.

Velopi’s project management training courses cover all the integration processes, including Perform Integrated Change Control. If this is of interest to you, our project management certification courses are held in Dublin, Cork, Limerick and Galway. Find out more by visiting our training page or by contacting us directly.

By Velopi Seamus Collins

© 2018 Velopi : PMBOK, PMI and the R.E.P. logo, PMP, PgMP, CAPM, PMI-SP and PMI-RMP are registered marks of the Project Management Institute, Inc.

Web Development by Granite Digital