Change Request Form
The change request form is pivotal to your change management process; it will capture all the information required to render a decision on
the requested change as well as administrative information such as routing,
deadlines, etc. Choosing the right template and educating your project team on
its use will make your change management process easier to control and monitor.
Choosing the wrong one will lead to missed information and increased manual
effort. IT organizations will frequently use a change request form to capture
operational changes and this form may be adequate for the needs of your
project. If it does not support your project needs, it may be possible to alter
it so that missing information is captured (and irrelevant information is
dropped). There are two reasons for making this your first option. Firstly, it
can save you time and effort and secondly using a form everyone is familiar
with saves on education time.
If a form is not available from your operational group, you
will have to design your own. Your change request form should be available to
the team so that every team member has access to it and has the ability to
complete it. This means that the template will have to be produced by a tool
which all team members have access to. MS Word and Excel are 2 tools which are
available on computers running versions of MS Office. Excel is especially
useful as it allows you to protect fields that shouldn’t be altered (e.g. title
and identification fields). Avoid using a tool which limits the team’s ability
to fill the form out. Using a .pdf form which cannot be edited will restrict
information flow as requesters must complete the form by hand; each subsequent
step will also be manual. You or your change coordinator will soon become tired
of all that walking!
Requesters must provide a text description of their request.
Some requests can be captured in a sentence or two while others will require
several pages. Using an electronic form will allow a requester to provide more
information than the stock field would hold. Provide a facility to append
documents to the change request so that lengthy descriptions and diagrams can
be attached to the request. This field should be used to capture the business
case for making the change which may be different from the technical
description of the change. This information will allow non-technical people
such as the project sponsor to decide on the change. Train your team to define
the benefits of the change in business terms such as how many hours of
operational effort or development effort would be saved by the change. Review
the information in this area and prompt the requester for additional
information or clarification if necessary. Circulating the request to a
technical SME who can’t understand what the request is asking for will cause
frustration and delay the change. Have the requester include any deadlines that
they are aware of in the description area.
The form must capture the contact information of the
requester so that they can be queried by you, the change coordinator, or the
SME. Information can include Name, Phone number, and e-mail address. Additional
information might include location, time zone, etc. and will depend on your
You may wish to employ a contact list in conjunction with
your change request form so that communication to your SMEs is automated. If
you use an issue tracking system to supply your change request form it may have
the ability to create and manage these lists for you. Most e-mail tools will
also support the use of contact lists to address e-mails; you can enclose the
change request with a standard e-mail or use an e-mail form to create your
template. Using e-mail as your communications tool will allow you to edit the
names in the contact list so that each request can be sent to a customized list
of SMEs. You can also use a public directory or wiki to post the change request
and e-mail to send notifications.
The form should also provide a field for analysis. The
analysis performed by the SMEs should result in a calculation of effort if the
request is feasible (or the reason it isn’t feasible if it is not). There
should be enough room in the form for all the SMEs to provide their effort
calculations and any information in support of the calculation. Once again,
creating a form which can expand the field will be useful. You will have to
support attachments to the form if there isn’t room enough to hold all effort
calculations. The effort aggregations should be summed to yield the total cost.
You will have to perform some analysis yourself to calculate the impact on the
schedule. Schedule impact will be influenced by the duration of the new
activities and the number of activities that can be performed in parallel.
The form must also capture the date the request was
initiated. This is the date the project received the request. This date will be
the base for all the other deadlines for the request. The current request
holder should also be captured. This will change as the request is
circulated and works in the same way as a trouble ticket. The due date for the
current holder to complete their work and communicate the request to the next
person indicated in the process should be captured. Try to have SMEs do as much
work in parallel as possible. For example, when a programmer, database
architect and software architect must analyze the request send it to all 3 and
set the due date for each SME. In the case where you send the request to
several different people and the amount of analysis effort differs, use the due
date for the SME who has the most work to perform as the due date for the
The form should capture the status of the change request. It
becomes "received” as soon as you process it. The status changes as soon as the
request is sent to SMEs for analysis and again when the change request is
awaiting a decision. The status is changed finally when a decision is rendered.
It may be "accepted”, "rejected”, or just "closed”. If the decision is not
captured in the status field, it should be captured elsewhere on the document.
The form should provide a text field to capture the reasons for the decision.
You may also want to capture the planned implementation date in the request
form should the requested change be approved. The form will be the
communications device that conveys information about the request to the
decision makers so ensure the information is complete and intelligible before
asking for a decision.
The change request should be frozen as soon as a decision is
rendered. The change request and final decision should be communicated to the
requester as soon as it is rendered. Make sure that the reason for rejection is
communicated should the request be rejected. Communicate the planned
implementation date if the request is accepted. The ability to change the form
by anyone on the team other than you should be disabled at this time and the
change request archived in a "read only” repository. This repository should be
a part of the project artifacts that will be part of the knowledge base made
available to future projects.
Your change request form should be the vehicle for all the
information your project requires about proposed changes. This information may
be distilled into other forms for reporting purposes (e.g. a Change Request
Log), but the form will be the source for information about the change. The
information you need to gather on this form will depend on your organization,
the nature of your project, and the communications tools used by the project.
Information can be divided into 3 categories:
a good job of designing the form for your project and then ensure that the form
is completed properly, in a timely fashion, and you will be well on your way to
controlling changes to your project. Failing to do so will hamper even the best
change management plans.
information – for example the requester’s contact information, who is
currently responsible for the request, due date for the next step, etc.
about the request – what the request asks for, the business case for the
request (the "pros”), etc.
information – the individual cost of the tasks, the aggregate cost, the
impact on project schedule, any fringe benefits not foreseen by the
requester, any negative impact on other deliverables, etc.
tips and tricks described in this article implement some of the best practices
promoted by the PMI (Project Management Institute). These are taught in most
PMP® courses and other PMP® exam preparation training
products. If you haven't been certified as a PMP® (Project
Management Professional) by the PMI and would like to learn more about
certification, visit the three O Project Solutions website at: http://threeo.ca/pmpcertifications29.php.
three O Project Solutions also offers a downloadable software based training
tool that has prepared project managers around the world to pass their
certification exams. For more information about this product, AceIt, visit the
three O website at: http://threeo.ca/aceit-features-c1288.php
|Change Request Form
||Change Request Form/Template