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
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
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.
over-run of your project’s buffer for analyzing change requests should be
analyzed as part of a lessons learned exercise to determine why it was
over-run. Either the buffer allocated was too small for the project or there
was a problem with the way the requirements for the system were gathered. It
has been my experience that the latter is far more likely to be the root cause
of the problem. This article isn’t intended to deal with managing requirements
there are a series of articles on the www.threeo.ca
website on the topic. Reading those articles will give you the ounce of
prevention you need to cure this problem.