Change Request Management

Change request management is akin to the software application testing in that both phrases give experienced project managers absolute nightmares. If it doesn't, then they haven't deilvered quite as many high profile, time sensitive projects as they would like you to believe!

So why should this be? After all there is a clear change request process, and surely project change requests (PCR) are nothing more than yet another paper exercise amongst the numerous others a project manager has to contend with.

If only it were that simple. You see change request management is a highly political process, through which a project manager requires all their diplomacy skills to exit unscathed.

All your project management stakeholders will have their own "pet" change requests which they will want to include. This includes new functionality which whilst in theory is included in the project scope statement (if you haven't been specific) is not detailed in the business requirements documentaton, Then there are major changes to existing defined functionality which is nothing more than blatant causes of scope creep. Finally there are "tidying up" exercises such as current live issues which should go into a maintenance release but due to issues estimating project costs (aka having no project budget) are dumped into yours!

It is quite frankly a nightmare which you have to manage. At a high level the best way to deal with this is to

• Manage expectations
• Be consistent in your approach to project change requests
• Demonstrate the lack of time available by creating a project plan which demonstrates this more clearly
• Have clear project cost controls and stick to them
• Emphasise your project resource scheduling to illustrate the project does not have the resources available to do the work required

Now a word of warning. I have been in this profession for many years and you can do all of this and it still won't make any difference. On one occassion I remember managing a project team which was in the process of being offshored, whilst the project had a launch date which if missed, mean't it couldn't launch for another year. There was no contingency approach for the simple reason that a day slippage mean't a day slip on the launch date.

Despite this the project sponsor insisted on raising a change request for new functionality for which there was no business case or project budget for. The impact assessment alone took the supplier 2,500 hours to do. That’s right just the impact assessment.

But it was only at this stage that the project sponsor finally gave in and agreed that we “probably” couldn’t deliver it!

Change Request Management - Tip

Whenever you hear the word change request, the first work which should spring into your mind is “NO”. Anything you can do to stop them being raised can only be a good thing, because once they get into the system they become infinitely harder to manage them.