Change Request Analysis Buffers

Your first line of defense against using your CR analysis budget up is the allocation of a realistic buffer to deal with change requests. There is no set amount of time for this; the amount of time required will be dependent on the number and complexity of the change requests you receive. The number of change requests you receive will depend on how well the requirements for the software system were defined. Care taken during the definition of requirements will pay dividends by reducing change requests and enabling the team to deliver the system their customers need. You shouldn’t need more than 5% of your SMEs time under normal circumstances, so that’s as good a benchmark as any to use when scheduling your project. You should also school your SMEs in what is expected of them in terms of CR analysis. Discuss the level of detail you require in your information and the amount of time the project can afford for the analysis with your SMEs and ensure they understand what is expected of them.

Still, "the best laid schemes o’ mice an’ men gang aft agley” (at least according to Robbie Burns) so there will come a time when your team gags on the last change request they’re given to analyze and tells you they can either analyze this change request or meet their deadlines for delivering the software. The first consideration here is when you get this warning. You’ll get it before the team has reached melt-down if you’ve done your change management planning properly and educated the team on the plan. Advance notice will let you react to the situation in a thoughtful manner rather than as an emergency. The response will be the same however. You have two choices at this stage. You can either add more time to the buffer assigned to change request analysis or you can stop analyzing change requests and concentrate on delivering the system.

The first option will require you to author a change request. Fortunately this change request won’t require your team to analyze it. You’ll need to forecast how much more time will be needed to manage all the change requests you expect to receive on top of the ones already in the pipe. Base this estimation on the amount of work left to do and the volume of change requests received over the previous period. You’ll either have to extend the schedule to accommodate the additional time or add additional resources to the project to deliver by the original deadline. You’ll have to increase the budget to accommodate the additional resources. This is a decision that should be made by the Change Control Board (CCB) and the project’s business sponsor should be a part of that body. Make sure that you can use the extra cash to secure the resources you need to provide the additional analysis. The closer you get to the end of the project, the more difficult it will be to deploy new resources.

Identifying low priority features that are less important than the analysis of upcoming change requests is an alternative to increasing the budget and extending the schedule. Identifying features that can be dropped in favor of increasing your CR analysis buffer will require the team identifying requirements to prioritize their list. Having the business sponsor, or their delegate, sign off on the prioritized list will allow you to identify the undeveloped low priority features which can be dropped in favor of the additional analysis buffer.

The last option is to halt further analysis of change requests. This step should be provided for in your CM Plan and the criteria for taking it clearly spelled out. You should vet this step with your business sponsor before taking it to make sure they are comfortable with it. You should keep in mind that the temporary (or permanent) halt of CR analysis does not necessarily mean that no further changes will be made to the system. There are alternatives which can be offered to the stakeholders. The halt to CR analysis should only apply to the current iteration, when an iterative method is being used. CRs which do not get analyzed during the current iteration should be held over to the next iteration which will have its own buffer for change requests. Projects employing the waterfall methodology present a problem, but that can be addressed by passing all future change requests on to the organizations operational change management process. This is a viable alternative in the case where the work is being done in-house and the system is maintained using a combination of bug reports and change requests.