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 project.

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 others.

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:

1. Administrative information – for example the requester’s contact information, who is currently responsible for the request, due date for the next step, etc.
2. Information about the request – what the request asks for, the business case for the request (the "pros”), etc.
3. Analysis 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.