Change is inevitable in any project. In project management terms change is defined as ‘anything which transforms or impacts projects, tasks, processes, structures, or even job functions’. Project change comes from the environment changes, user requests, risks and issues and many other areas.
Irrespective of the source of the change, it needs to be managed and controlled effectively to ensure no unnecessary changes are made, all changes are documented, services are not unnecessarily disrupted and resources are used efficiently.
This blog discusses an effective project change control approach recommended by PRINCE2 and an overview of how Insentra applies this approach to our project management methodology.
CHANGE CONTROL APPROACH
PRINCE2 recommends five steps in the project change control approach – Capture, Assess, Propose, Decide and Implement as per the diagram below:
Before we go into the details of the steps, we need to understand the definition difference. In PRINCE2, changes are identified as ‘issues’. PRINCES2 uses the term ‘issue’ to cover any unplanned event requiring management action during the project. Issues may be raised at any time during the project by anyone with an interest in the project or its outcome.
There are three types of issues: request for change, off-specification, problem/concern. Now we will look into the request for change and the change control approach recommended by PRINCE2.
Capture
The first step in the change control approach is to undertake an initial analysis to determine the type of change raised and make an assessment of its severity and priority.
Changes should be entered in the change register (PRINCE2 uses Issue Register) and given a unique identifier.
Assess
Assessing the impact of the change on the project comes next. The impact analysis helps us to understand the extent of the change and other products (deliverables) which may be affected.
However, the project manager needs to consider whether it is worthwhile performing a detailed impact analysis as the duration and effort required to undertake one in itself may cause a deviation from the plan.
The impact analysis should consider the impact the change has (or will have) on:
- The project performance targets, in terms of time, cost, quality and scope, including whether there are any other products within the project’s scope also impacted by this change
- The project business case, especially in terms of the impact on benefits
- Any other dependent products produced by the project
- The project risk profile (i.e. the impact on the overall risk exposure of the project)
Assessing the impact of changes not only refers to the impact a change has on a customer. Impact analysis must cover the three areas of business, user and supplier. It should include the supplier’s cost and effort required to implement a change and what products would have to be changed. Once this impact analysis is complete, the severity or priority of the issue should then be re-evaluated.
The change register should be updated to include the above information and the person who raised the change kept informed of the status.
It may be necessary to request advice from the Project Board to confirm understanding (or position) of the change’s priority or severity before proposing resolutions or treatments.
Propose
Under the propose step, we look at the options to deal with the change and prepare a recommendation for the change authority.
Consideration should be given to the effect each option has on the project’s time, cost, quality, scope, benefits and risk performance targets. There must be a balance between the perceived advantage gained by implementing an option and the time, cost and risk of implementing it.
The risk considerations should include both project risks (i.e. of not completing within tolerances) and risks to operational performance when the project product is in use.
If any of the proposed options would take the stage or project beyond any tolerances, seek advice from the project board. The project manager should execute the decision by the project board in response.
Decide
In the Decide step, the change authority decides on the recommendation.
The project manager may be able to resolve changes without the need to escalate them to the project board. For example, a minor change to an approved detailed design document which does not affect any other products could be handled by the project manager under their discretion and recorded as such, if allowed in the change control approach.
Other changes may need escalation to the project board or its delegated change authority for a decision.
Implement
Finally the decision is implemented.
The project manager will update the change register with the decision, implement the change and inform all stakeholders.
Implementation of the corrective action must ensure the baselined products are updated in a controlled manner and with appropriate authorisations. If a product which has been baselined is to be changed, a new version should be created to accommodate the change and baseline version is kept unchanged. Old baseline versions should be archived where possible, not discarded.
CHANGE CONTROL APPLICATION
Similar to many other project management methodologies, the goal of adopting a method in project management is not to overburden the project manager, but to provide tools and an appropriate level of control within an acceptable level of risk. In addition, an organisation’s project management method should form a seamless part of the organisation’s overall governance and management systems.
At Insentra, our project managers strive to accurately manage project changes to deliver projects against performance targets in terms of time, cost, quality and scope. We apply the change control approach to suit our unique and proven channel delivery method and project governance.
When a request for change is raised, we capture the change in the Change Log within our project management tool, which also tracks risks, actions, dependencies and so on. Following the impact assessment on the scope, schedule, budget, resourcing and risk, we raise a change request, in which we document the cause, propose our recommended option and outcome and record lessons learnt.
Once a change is raised by a project manager, we seek support and agreement from the project team members on the content. The Solution Manager or those with responsibility or accountability for the partner, client or sales process might be asked to endorse the change. Following the endorsement, the change is sent to our management for approval. Once we have agreement within Insentra, the change is presented to our Partner and/or their client for their review, processing and approval. After a decision is made through this change process, the project manager will implement the decision.
By tailoring the PRINCE2 project change control approach, Insentra is able to manage project changes effectively and efficiently and ensure all project stakeholders are collaboratively and collectively involved in the decision-making process relating to project changes.
I have now quickly walked you through the Project Change Control recommended by PRINCE2 and Insentra’s process tailored to suit our unique and proven channel delivery approach. I hope understanding this methodology and seeing how we implemet it provides you with value and you can see benefit in applying it to your own projects.
