Project Management Books | Project Change Management.

A project change request is a request during the life of a project to change a signed off project deliverable. So, once the PDD has been signed off, if later in the project someone wants to change the project scope they raise a PCR. Once the User Functions Design document is signed off if someone wants a change to the design they raise a PCR. We are not discussing here changes that are requested to live systems - we would call these Improvement Requests. However, if an improvement request is raised and a live system is changed and there happens at the same time to be a project underway to enhance that system, we may also need to raise a PCR to reflect the change to the live system in the copy of the code the project developers are working on.

What happens if continuous, unbridled change is allowed during a project? The project will go on for a very long time and may never finish. At the other extreme allowing no change at all is a nice idea but would probably mean that whatever was delivered wouldn't meet the business need.

Almost always in a project some change has to be taken on board as the project progresses. Clearly we need a process for managing that change. A key aspect of this process is deciding, at the start of the project, who will be authorised to spend the company's hard-earned cash on changes. We will consider later who this should be.

How will the PCRs be administered? If only a handful of PCRs are expected the project manager can administer the PCRs himself. But some projects, notoriously software projects, get hundreds or even thousands of PCRs in which case a project office will be needed to handle the administration. For medium sized projects perhaps a team leader can look after the paperwork.

Putting the change hours in the right team members' plans at the right time is very difficult, but the change hours must be put somewhere in the plan. If in doubt put the change time at the end of the stage plan as we discussed in the planning chapter.

Never muddle the change budget with contingency. There should be a clear, separate budget for change with a clear owner. Contingency is there for anything else that might crop up. Though one reason for spending contingency could be that there is more change than expected and contingency is raided to fund it.

Of course, one could begin the project or stage with a zero change budget. Every change that is accepted increases the project budget and, in principle, moves the project end date. However, this will almost certainly be perceived as failure.

Setting aside 5%-15% of the stage budget for change is typical and may be broken down into three pots:

A project might spend more time investigating PCRs than actually making changes. Why might this be? Having worked out what a change would cost everyone decides it's not worth doing. In a way this is a waste of money - investigating a PCR that then gets rejected. We will see how we might limit this wasted expenditure.

In the first box (please have a look at the form below) the person raising the PCR says two things: what change they would like and why - what is the business justification for disrupting this project half way through; who raised the PCR; and when was it raised.

The PCR then goes to somebody - say the IT team leader - whose first reaction to a PCR is usually a sharp sucking-in of breath: "tch, oooh, just to investigate this change request would take me two days." We now have a 14 hour estimate just to investigate the impact of this PCR (the first line of box 2).

Somebody should now have to make a decision: do you want to spend 14 hours worth of the company's hard earned cash to investigate this PCR or not? At the extremes PCRs come in two sorts. At one extreme everyone know the PCR has to be done so we get on and do the impact analysis. At the other extreme, particularly in software projects, there can be hundreds of 'bright idea' change requests. An extreme example of that: we are half way through the build step and some bright spark thinks it would be a nice idea if one particular web page, rather than being green on black, flashed on and off bright pink but only on February 29th every leap year. Just a bit of fun for our customers.

This great idea goes to IT who say it would take a month just to establish if that was feasible, let alone the cost of doing it. At this point even the bright spark who had the idea would say: "forget it!". The point is that one can save wasting limited PCR investigation time by saying what the investigation would cost.

Project Change Request (PCR)
Project:							PCR No:
Description of Proposed Change and Business Reason:
Submitted By:							Date:

Estimated Hours to Investigate Change Request:
Accept Reject For Investigation			Project User Manager				Date:
Accept Reject For Investigation			Project IT Manager				Date:
Reason for Rejection: (add attachments if necessary)

Actual Hours Spent Investigating Change Request:
Description and Impact of Change: (add attachments if necessary)
Estimated Implementation Cost By Phase:	Current phase			Phase:	Phase:	Phase:		Total Hrs:
Estimate Valid Until: (delay will increase change cost)
Approve Disapprove For Implementation:		Project User Manager					Date:
Approve Disapprove For Implementation:		Project IT Manager					Date:

Project Management Book

...chapter 11 continued