About Me

header banner

Modifying a vanilla Change process to handle a higher volume of Change Requests

I have previously spoken about the need for a solid Change Management process within your Project. Although undesirable, sometimes you are faced with a Project that has to cope with high level of change requests. In such circumstances, I tend to modify my vanilla 4 step process to give you the best chance of coping without totally derailing project progress.
Projects - Coping with a High Volume of Change Requests

Simplified 4 Step Process for most Projects

Before going onto address a process for Projects with high volumes of change requests I want to recap on my vanilla 4 step process which I explained in a previous post and should be suitable for most Projects up to say 4 Request for Change (RFC) a month on average. The 4 steps are:
  1. Submission of a Request for Change (RFC)
  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

Key Messages regarding Projects with High Volume of Change Requests

Firstly, let me remind you of some key messages re high volume of Change Requests:
  • 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 across all lifecycle phases. Therefore even if every Request for Change (RFC) is rejected, the actual change process can derail a project. A sensible PM makes some allowance for running a process with a low volume of RFCs but if the volume gets too great, this should be taken back to the Project Board / Sponsor
  • A Project is all about delivery of something to achieve a business 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 your next Project Board meeting
  • So in summary, remember the proverb "If project scope is allowed to change freely, the rate of change will exceed the rate of progress"
If Project scope is allowed to change freely - the rate of change will exceed the rate of progress

So after these considerations you still need to handle the high volume of Change Requests - I recommend optimising the vanilla 4 step process. I should note that this process is tailored to IT projects although the same principles apply to other project types.

Nominate your Change Champions

Nominate three people empowered by the Project Board as Change Champions who, with the PM, will handle new RFC load on a daily drip-feed basis:
  • Change Requirement Champion, someone from the business who has best overall understanding of the requirements (Senior User?)
  • Change Technology Champion, someone from technology who has best understanding of the technical work to meet requirements e.g. architect
  • Change Business Champion, either the Sponsor themselves or more likely a proxy who can represent the Sponsor. This person has their eye on the Business case
Although these are 3 separate roles, one person can take more than one role which can make it easier. So a good example might be the Senior User covering Requirement and Business champion roles in the process.

Revised Process using Change Champions

  • Step 1 – Filter out the obvious ones. The Change Business Champion validates the Business case against where the project is within the project life-cycle and the criticality of the RFC. Reject if not valid and thus minimise wasted effort on impact assessments
  • Step 2 – Change Technology Champion undertakes a fast and high level “initial impact estimate” of the RFC involving the Change Requirement Champion and others as necessary but the effort should be no more than 1-2 hours
  • Step 3 – Change Technology Champion works with Project Manager within this couple of hours effort to quickly assess the RFC against the Project criteria (Note: this is not a committed estimate/ impact assessment, it is just intended to give a scale of the likely impact e.g. trivial or it will derail key milestones)
  • Step 4 – Change Business Champion makes a decision based on the “initial impact assessment” whether this is a RFC which is important enough to probably be approved at a Change Board even considering the likely impacts or would be rejected / postponed (e.g. to a future release for example)
  • Step 5 – Only if the Change Business Champion authorises a RFC for a full impact assessment, a more detailed and committed impact assessment is produced for consideration and approval in the next Change Authorisation Board. In emergency “time critical” situations in the project life-cycle where, say, time impact will be greater day by day until a decision is made, the Business Champion may authorise work to commence on the change based on the initial impact assessment. A full impact assessment is produced in parallel to the work commencing

Conclusion

This enhanced process should give you a better chance of coping with the high volume of Change Requests - but much better to not be in this position at all :-)

Post a Comment

0 Comments