The Processes Involved in Change Management

I started off intending to write a straightforward blog post about change management from the project manager’s perspective – change management the conventional way; that focusses on processes within an organisation and how they are used to effectively control changes in projects. To a certain extent that is still what I am going to do (mainly because there are still so many organisations working in a process-based way) but I also want to briefly mention change management via “Viral Change^TM“.
I recently came across the work of Dr Leandro Herrero that describes how “viral change^TM” can be used to control and manage changes but with the emphasis on behaviours rather than on processes. Viral change^TM views an organisation as a living, flexible and adaptable network (yes, that would be nice wouldn’t it) and focusses on language, behaviours and company cultures.
I’m planning to read more in Herrero’s book “Homo Imitans – The art of social infection: Viral Change^TM in action“.
But back to the conventional route to managing change within a project.
All but the simplest of projects will encounter requests for changes during their life and how these changes are managed will affect whether the project is a success or not. So right at the outset a process should be established for requesting, reviewing, approving and managing any required changes. Such a change control process will ensure:

• A formal mechanism for requesting a change
• A clear process for approving or rejecting changes
• Feedback to the client/user on requested changes
• Better communication to all concerned
• Changes are incorporated into a project in a controlled manner

Clearly the approval or rejection of a change request is an essential element of change management so it is important to establish what criteria are used in this decision and who is responsible for making the decision.
Each change request should be assessed on the basis of:

• Business case – is the change really necessary or just a “nice-to-have”?
• Business benefit – will the change deliver measurable improvements?
• Resources available – is there time or manpower to implement the change?
• Risks – what risks would the change pose to the existing elements of the project?
• Quality issues – could the change impact the quality of other areas?

Every approved change will affect the schedule, documentation and test plans so the process must ensure that these are all altered accordingly.
Change Request Status
 
From the point of submitting a change request to closing that request there are a range of statuses that the request can pass through so these must be defined and communicated to the person or group that raised the change request, other stakeholders and the client. Automated change management systems can send an automatic email notification to concerned parties each time the status changes with the reason behind the change in status.
 
Typical statuses might be as follows:
 

1. Submitted – a formal Change Request has been logged
2. In Review – the change request is undergoing review to approve or reject it
3. Approved/Rejected – the decision has been made and reasons documented
4. Scheduled – approved changes have been incorporated into the project schedule
5. Completed – the change has been made
6. Awaiting Test – the changed product/function is ready to be tested
7. Accepted – the change has been tested successfully and accepted by the client
8. Closed – the change is fully implemented

 
 
Change Request Procedure
 
The typical procedure for managing a change request might be as follows:
 

1. A formal change request is submitted with all necessary information – this would typically be done via a form or through an online tool to a central repository depending on the maturity of the change management process, size and complexity of the project and/or organisation.
2. The request is evaluated to determine whether it is a valid request and all necessary information/reasoning for the request has been supplied, including the business case/benefit.
3. The request is reviewed by the stakeholders, project manager and any others potentially impacted by the change. Additional information such as an estimate of time to implement, risks (of implementing and not implementing), impact on existing tasks in the project etc are obtained and used for this review.
4. Stakeholders and project manager decide whether to approve or reject the change. There can also be an option to postpone the change (i.e. until after project delivery) if this is feasible.
5. Rejected changes are returned to the requester with a written explanation.
6. Where changes have been approved the budget and/or resources are adjusted accordingly or, when this is not possible, the project manager must negotiate the removal of other lower priority tasks.
7. Depending on the number and type of approved change requests it may be necessary to prioritise them; typically based on factors such as whether failure to implement the change will undermine the usability of the final product, whether workarounds are possible and whether user training could mitigate the problem.
8. Approved changes are incorporated into the project plans and schedule which are updated with respect to risks, dependencies and deadlines.
9. Approved changes are incorporated into other areas of the project such as the requirements documentation, test cases and user documentation.
10. On a regular basis a change control report can be produced showing the status of all change requests and their impact on the project over time, with respect to changes to budget or schedule.

Effective change management through a formal process prevents scope-creep which helps keep the schedule on track but also ensures the end product is fit for purpose.
Why not share your thoughts or experiences of change management with us?