Every project will be subject to some form of change over its lifecycle. In the post, Overview of project change control process, I covered the 5 core steps:
- Identify change
- Impact assessment
- Review change request
- Approve / reject change
- Implement change
This post is going to expand on step 1, Identify Change.
Who can raise a project change?
The simple answer is that anyone should be able to raise a change against a project. This makes sense as a driver for change can come from any number of internal or external sources.
The reality is that change will come from a much narrower set of people who are close to the project.
Why is this important?
It is important to have the principle that anyone can raise a change, as this helps protect the project from missing an important change in circumstances that will impact the successful delivery of the project.
It also helps reduce the risk of the project team not paying attention to concerns being raised from outside the project team.
For example, if a project has a very tight deadline, they may not be receptive to someone trying to raise a change if it will impact the delivery. However, there is no benefit to meeting the delivery deadline if what is delivered does not meet the required outcome.
Word of caution
While it is a good idea to allow anyone to raise a change, it does need to balance the time required to review and impact assess potential changes.
As with most things in project management, you must adopt a pragmatic approach.
Identifying project change process
It is important that there is a structured method on how change is identified across the project.
In order to support this, it is critical that there is a published change control framework, that has been communicated, for the project.
This should include details on how an individual can raise a potential change.
As there is not a set time when a change may occur, it is important that all stakeholders are made aware of the process for raising a change.
Tip: it is a good idea for the PMO to have a regular agenda item for formal and informal meetings to ask if there are any new changes.
Change request form
When a potential change is identified, it should be raised on the defined change request template. This should allow the capture of:
- Change request title
- Name of requestor
- Date
- Project
- Brief overview of change
- Reason for change
- Impact of not implementing change
- Date change required
The aim is to allow for the change to be understood and to allow the impact assessment to be completed.
Change request identification triage
It is likely that some changes will not progress or not even be true change requests. Therefore, it is a good idea to implement a triage process.
The PMO can help by implementing a process where any potential change is discussed first to see if it is appropriate. If so then the change request form can be completed.
The next phase of triage is after the change request form is populated. A further check can be made to see if it still makes sense to progress. If it does this acts as the QA step to ensure the change is ready for impact assessment.
These checks can save a lot of time for the project. However, they must also ensure that genuine requests can be raised.
Proceed to impact assessment
If the template is complete and deemed a change, it can then be captured on the change log and be sent for impact assessment.
Summary
The most important points of identifying change requests are:
- A structured change request process
- A change request template to capture the change
- Regular communication of the process
- Triage process to help ensure only genuine requests are raised
