Back in November, I wrote an article about the life cycle of a change request, and noted that fifteen of the forty-two processes documented in the PMBOK may produce change requests. More recently, I’ve had occasion to ask: what are our integrated change control processes trying to control? Because it’s obvious that some projects need to facilitate changes and some need to resist changes, based on the larger context of the organization and the goals of the project, in terms of the constraints under which the project was initiated. In short, different projects need to optimize for different parameters. So let’s consider some alternatives:
- Optimizing for schedule – if a project has a drop-dead date that can’t be adjusted, then change control should facilitate changes that reduce risks associated with meeting that date, and resist changes that increase the risk of delivering late. Note that such dates tend to be assigned by some external authority, for reasons that can’t be seriously challenged without also considering cancellation of the project.
- Optimizing for cost – if a project has little or no tolerance for cost over-runs, then change control should facilitate changes that reduce risks associated with cost increases, and resist changes that increase the risk of cost increases. This is especially true if the project is being performed under contract.
- Optimizing for quality – if the deliverables of a project warrant placing a premium on quality, then change control should facilitate changes that reduce risks associated with errors, and resist changes that increase the risk of errors or defects. If you’ve ever delayed a roll-out in order to remove critical defects from a software product, you know what this is about.
- Optimizing for compliance – some projects have external requirements that are absolutely non-negotiable, and all other considerations are secondary. Let’s face it: you can’t accept unnecessary risks with some projects, like payroll and other financial calculations, or avionics.
- Optimizing for value – if a project is to be truly transformative for the receiving organization, then change control should facilitate changes that add value without unduly adding risks and resist changes that add more risk than is warranted by the value added. When people extol the virtues of an Agile approach, this is usually what they have in mind.
Note that I’ve expressed this in terms of managing risk; while you can always argue a business case for a specific change, integrated change management has to consider the totality of the project, and the overall risk profile. We should resist adding the widget that breaks the camel’s back, and facilitate adding the one that improves the overall outcome.
There are probably other parameters for optimization. If you can think of some, please add your comments!