Project Management Books | PCR Control. Change Control. Project Change Control Form.

If we decide to investigate the PCR, someone establishes what the change would cost and what its impact would be on the project's schedule. Let's say (box 3) it takes 12 hours to do this investigation. That's 12 hours spent from the change budget, we can't spend it again.

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:

And, for example, the investigation reveals that the impact of the PCR would be a 2 week delay to the project end date; 100 hours (£5000) extra work in the current step (let's say we're in IT technical design), 50 hours extra cost in the build and test step (another £2500) and 80 hours extra user testing time (£3000). So total cost 230 hours (£10500).

Very simply someone can now make an informed, business-like decision: does the benefit of this change justify the date hit and the extra cost (and justify jeopardising quality - see the next chapter). That's all the PCR process is trying to do: let the paying customer - the user - make informed decisions about change.

On the form (again, any form is just an example to help you devise one appropriate for your project) you'll notice the 'Estimate Valid Until' box. Imagine you're having a house designed and built for you. The design has a 2 car garage. You ask what it would cost to change it to a 3 car garage. The builder says it depends: if you make your mind up by the end of the week it will be £1000. But next week the foundations are being dug and concrete poured, so the £1000 estimate is only valid until the end of Friday - leave it later and it will cost you an ever increasing amount.

On a large project this approach can galvanise people into making timely decisions on change: make your mind up by Friday or it will cost you more than this. This helps prevent a large number of change requests sitting around awaiting decisions, each of which is a potential source of project disruption.

Where do change requests come from? If you're not careful they will assail you from all directions: the users change their minds (for good and bad reasons), the IT guys have great ideas for 'improving' the design, company policy changes, unforeseen external events affect the project. But unfortunately in software projects most change requests result from two causes:

When running a software project we would recommend that each change that is taken on board is categorised by cause. If you discover that most change is caused by vague requirements that will drive you almost subconsciously to invest more on the next project in getting the requirements right: rigorous, hothouse requirements definition workshops, etc.

If you were a non-technical person managing an IT project and one day a techie said: "boss, please can you sign off this PCR. We want to change the name of this object from XYZ-3 to XYZ/3. The cost is virtually zero, there is no impact on the user's view of what we'll deliver." Would you really want to see that change request? You wouldn't even know what they were talking. But if changes of that sort are not carefully managed amongst the IT team there could be chaos.

So you might invite the IT team leader to run his own cut down PCR process for these small technical changes. But be careful: this can become a back door change control process through which things get slipped that should have come to your attention as project manager. Sit down with the IT team leader every now and again and get him to talk you through the changes on the small change log and woe betide him if you understand any of them.

Clearly, at the other end of the spectrum there could be a PCR that would cost more than the whole change budget. Obviously the sponsor would need to approve it as it would increase the project cost.

Before you begin you might decide that any PCR that would cost more than 25% of the change budget will not come out of the PCR budget, they will be an addition to the project budget - the PCR pot will be used only for changes smaller than that. Indeed, you might draw a matrix that shows for each type of change who has to be involved in investigation and consideration of it and for each size of PCR who has to be involved in approving it. So from the outset you know that a technical change costing less than £x can be handled by the IT team leader, but a business change costing more than £y needs a decision by the sponsor. Work out the rules of engagement before each stage begins: the rules will probably be different for each stage and may even change during a stage.

Project Management Book

...chapter 11 continued