Projects don't prevent change, they control it. We need to make sure that we don't have unauthorised change, commonly known as scope creep, where changes are made without the correct authorisation or approval. So, the change control process is a formalised way of ensuring that changes are made and that the baseline documents are updated to reflect those changes. The change control process has essentially five steps. First of all, request change. Somebody has to ask for the change, it has to be requested. So, you could call that a request for change. That is put forward in some form of documentation, and we would update what's often called a changelog, or a change register, to show that that change has been requested. We could then carry out what's called an initial review. Now, the initial review step is an-, a high-level overview. A high-level assessment, where we could look and think, 'Okay, is this a good idea?' We wouldn't spend too much time analysing it, but it's a step where we could maybe instantly reject it because it's vastly over budget or would cause such a negative impact on the project, or we could look at it and think, 'Actually, this is something that is worth investigating.' So, the initial review could be a high-level yes or no, but let's say this looks like something we want to investigate. A change that would be a-, beneficial to the project or organisation.

So, the next step would be a detailed assessment, and a detailed assessment will provide an in-depth analysis of the cost and time implications and the risks. What are the benefits for this change? So, this is our cost-risk-benefits analysis. Based on that, the next step would be a decision. Do we approve the change, say yes, do we reject the change, say no, or do we defer the change? Maybe put it off until later when more information is available. Now, if the decision is a no, we would go back and update the changelog, just as we would have done if there was a decision made in the initial review or in the detailed assessment. If the decision is defer, we would update the changelog, but if the decision is a yes, we would then go into the implement step, where we would implement the change. So, we would put that change into effect, and we would have to update baseline documents. And baseline documents is anything that's been versioned. Let's say the project plan. We need to update the project plan from version one to version two. The business case. We need to update the business case from version one to version two. So, the implement step would enable us to update any baselined project documents that need to reflect that this change has been implemented.

So, templates provide consistency. People can put forward a request for change in a way that is easily readable, we know what the headings will be. It will tell people, for example, to put what the request for change is, why the request for change is being put forward, and templates can often provide advice and guidance on how to fill out the form. But it can also give stakeholders an accurate understanding of the, the reasoning behind the change. Why do we need this change? And it can also give those stakeholders a full understanding of the impact that the change would have on the project. So, standard templates work in conjunction with a changelog to make sure that any requests for change are put forward in a standardised way, and recorded so we can keep track of any requests for change.

The change control process

About