The Ancient Greeks called it correctly - "Everything changes and nothing stands still"

In 500 years BC Heraclitus, the Greek philosopher, stated "Everything changes and nothing stands still". He could have been speaking of most Projects. If you were to bring the quote into the 21st Century you would say, "Some change is inevitable....except from vending machines" :-)

So with some requests for change inevitable during the project, as a Project Manager, you need to have a process to manage these requests else face chaos. PRINCE2 has a Change Management process but I tend to utilise a cut down version. In PRINCE2, every Request for Change (RFC) is supposed to start with an Issue but I believe this is a little excessive. 

Simplified 4 Step Process

I run a simplified 4 step process:

1. Submission of a Request for Change (RFC). Ideally have a form for this so it is clear who is requesting (sponsoring), what the change is (a new or changed requirement?), the business case for the change etc and I always like a section regarding the impact of the RFC being rejected (is there an alternative approach, maybe a manual workaround in the IT world)
2. This RFC is logged (in the Change Log) and allocated a unique number
3. The RFC is evaluated for impact on the project e.g. Effort/Cost, Impact on baseline plan etc
4. The RFC impact then needs to be approved by the Change Authorisation Board. This could be a separate body working under the Programme / Project Board or the main Board themselves (explained later)

If approved, the RFC then needs to be implemented and appropriate products updated accordingly.

Can't the Project Manager approve the RFC in some circumstances?

Some suggest that a Project Manager can approve a RFC as long as he/she is not forecasting going outside cost and time tolerances. I believe that this is bad practice. Tolerances are provided against risks identified by the Project Manager not to handle changes. In principle, the Project Owner (Sponsor or Project Board) should have or obtain additional funding for changes. Clearly if the forecast spend is really healthy I will be happy to use baseline budget but not typically contingency funds. In terms of timescales, even if I believe that a change can be delivered within the baseline delivery milestone I will likely highlight increased risks to the Change Authorisation Board i.e. if you approve this RFC, it should be delivered within the baseline milestone but will increase the risk of slippage.

What is the Change Authorisation Board?

In the simplest projects this will be the Sponsor. It can also be augmented by other members of the Project Board where one exists. In more complex projects or Programmes (especially where a higher number of Change Requests are anticipated) a specific Change Authorisation Board is recommended with timetabled meetings established. This will ideally have the Sponsor in attendance but will have other participants from the business and the project team and the meeting makes the decision (but with the Sponsor having the ultimate say, if present)

Some Golden rules of Change Management (especially within IT Development projects)

1. If you don't have some baselines in place (e.g. scope, requirements etc) you don't have the basis for a change control process. I have come across the odd business user who thought they could resist signing off anything and thus be free to change their minds many times. Safe to say, that got escalated to the Sponsor / Project Board pretty quickly!
2. The cost & impact of a change is greater the later in the Development cycle it is made
3. You need to consider many dimensions in your impact assessment - e.g. Time, Cost, Quality / Scope, Business Case, Risk, Products to be updated
4. Running a change process takes key individuals away from doing other planned work to ensure requirements are understood, estimate and aid the Project Manager (PM) in impact assessments. Therefore even if every RFC is rejected, the actual change process can derail a project. A sensible PM makes some allowance for running a process with the odd RFC but if the volume gets too great, this should be taken back to the Project Board. I also have adapted the process to cope with higher volume situations, a subject I will return to in a future post.

And finally...

A Project is all about delivery of something to achieve a benefit case and too many changes of direction can put the delivery and thus the benefit case at risk. If you detect this could be occurring, this is one to flag in bold and discuss at with your Sponsor or Project Board. As you might expect, I have a Proverb to explain....

But if you are still faced with lots of Change Requests being raised (which the Project Board agree that the Project needs to handle), you should consider optimising the process from that described above which I have covered in this post on Change Management for high volume scenarios.