Topic 11.12: Change management
Changes might take advantage of an opportunity, respond to a threat, or remedy the influence of an external factor that has thrown us off course.
However, because projects are complex beasts, with a vast array of stakeholders and moving parts, these changes need to be systematically managed so that the project remains focused, coordinated and understood by all.
Therefore change should not just ‘happen’ in projects.
It should follow a formal process of request, consideration, approval, communication and delivery to ensure that the change is in the holistic best interest of the project and its stakeholders, and that no-one gets left behind.
And although any stakeholder can request a project change, managing the process is the responsibility of the project manager.
Typical sources of project change include:
Late clarification of requirements
A desire to enhance the deliverables
Corrections to poor planning (eg inaccurate estimates, insufficient resources)
Identified bugs or defects
Changes to corporate strategy
Regulatory change, or
The emergence of new technologies
Essentially, every change request answers the following questions:
What needs to be changed?
Why does it need to be changed?
What are the alternatives (including what will happen if we don't make the change)?
How will it impact time, cost and scope (or even other projects)?
When (and by when) should it happen?
If approved, who will be responsible for it?
If that looks like a mini-business case, that’s because in many respects it is!
The processes that you follow in business case development – from stakeholder engagement and opportunity definition, through to cost/benefit/risk and even multi-criteria analysis – can all be applied here.
In fact, when making significant changes to a project, you should always go back and check that the assumptions and expectations of the initial business case remain undisturbed.
On many projects, the project manager is delegated a limited authority to approve certain types of change requests, while the sponsor may approve others, and the steering committee – or a dedicated Change Control Board (CCB) – will approve, reject or escalate the rest.
Note, too, that if the project is being delivered under a contract, then some proposed changes may need to be approved by the customer.
Approved change requests can require new or revised cost estimates, tasks to be added, schedule adjustments, resource requirements, and an analysis of risk.
Approved changes will therefore inevitably require updates to the project management plan, and it is important that someone is assigned the responsibility for communicating these changes to all affected stakeholders.
On larger projects, all change requests, whether pending, approved or declined, may also be kept in a change log.
A change log can be used to readily index and sort changes by priority, status, activity, phases or owner, among other fields.
Review of this log will form an important part of the project review and continual improvement process.
It should be noted that in software projects, the [changelog] file is the configuration record, something we will talk about in the next topic.
At the end of the day, changes to the project management plan are inevitable; rarely does a project manager finish a project with the same project plan they started with.
Uncontrolled changes, however, will create confusion, which will erode commitment to the project.
For if changes are not managed properly, you will experience unacceptable schedule slips, significant cost overruns, and reduced product quality.
Effectively integrating a process of change control is thus essential to the successful delivery of any project.