Documentation of Change Requests – an element of a Change Control Procedure

In addition to the lessons learned I shared here in regards to the application of change management techniques on different types of projects, I mentioned of a change control procedure we follow to ensure no unnecessary changes are made in the system and the required changes (as well as new requirements) are well documented & assessed before they are planned for implementation. Here in this blog I’ve described the important elements of a Change Request which, if documented well, could actually contribute in successful implementation of the change, from solution and people perspectives.

Detailed Documentation

Typically when a system change is requested by business, it’s very vague in terms of its description. To ensure everyone, among the stakeholders, is aware of what’s going on, the change request has to be documented. I’ve described the steps of documenting the change request here and welcome the experts to provide suggestions, if they have any.

The Basics

To classify the Change Requests appropriately, you should capture following type of information:

• Initiator (Person / Role / Organizational Unit): The person who raised the request as well as his role within the organization. You may, with mutual understanding, could settle on an authorized individual to raise such requests. If someone else within the department requires system modifications, should go through the person in-charge.
• Dates (Request / Plan / Implementation): The date a request is raised is the starting point. The plan of implementing and actual implementation dates could be updated as soon as there’s some progress.
• Priority (High / Medium / Low): Not all of the requirements raised by business require urgent solutions. Hence, marking the priority could help you in managing your time appropriately.
• Type (General / Specific): Some of the business requirements are cross functional and hence has different impact than the specific needs. While you mention the type, it’s also good to provide some details.
• Classification (Functional / Technical / Hybrid): A to-be solution for specific business requirements could be purely function and as such just require system configuration while another solution may require customization. To handle the requests internally by support team, classification could help.
• Reference (Helpdesk / Documentation / Evaluation): Whenever a requirement is raised, say in a helpdesk system, it is assigned a reference number to track the progress. Other references, while a Change Request is documented, could be the people who document and evaluate the requirements.

The sequence / format of the basics could vary and even additional points could be added depending on the support model / process in practice.

Business View

As a SAP Support Consultant, you may expect to get requirements which apparently may not make any sense to you. It’s absolutely normal; the business users are looking at their problem and not the technical details, so it’s quite probable if they mention the requirement unclearly. What you can do to understand and capture the requirements is to ask them to

• Provide the details in business terms and to be vocal about the scenarios in which such change is required along with justification (often with face-to-face meetings you could reach to some conclusion),
• Consider the alternates available which can meet business requirements by changing the practice (of course you’d need to demonstrate them if there are options available),

Now you could use the feedback to document the exact business requirements. This would serve as a baseline to document the rest of details of a Change Request.

Technical Perspective

After understanding the business need, being technical consultant, you could visualize what a to-be solution would look like. The details you could/should mention on the documented CR are:

• Technical Set-up (Configuration / Customization): Specifying which areas of system would require configuration / customization could help decision-makers on deciding whether / when to go for the implementation. However, it should be high level which help readers in determining the major technical components.
• Integration Aspects (Unit / Integration Testing): A request causing change in specific business process could have impact on some other processes. Hence it should be clearly mentioned to alert relevant people / departments beforehand. It may include testing effort required at different ends.
• Data Maintenance (Transactional / Master): Some of the changes require updates in master data. For some others, the requirement might include capturing additional transaction data. A clear indication on the impact on data should also be described to give a clear picture on the volume of the change implementation under consideration.
• Business Impact (Procedure / Process Changes): In some of the cases, change in system results change in procedure or process. A high level description of the business impact such as awareness and training requirements should be highlighted as well.
• Coverage (Included / Excluded): While documenting a respective CR being clear on assumptions you have made as to what is included and what’s not, could save both parties (the business in IT) in expecting the outcomes of the said change, should it be considered for implementation.

Management / Administration

Since the actual execution of the project is dependent on a plan, you may need to provide an overall effort estimate required by you / other resources within your team. To do so, you could break-up the effort as follows:

• Milestones: Specify the major phases of implementation such as Prepare, Explore, Realize and Deploy for instance,
• Activities: List down all of the activities required to complete individual phases with duration (number of days),
• Allocation: Mention who needs to do what. For example, if you are functional consultant, you provide your estimate. For technical, you could send it to your counterpart to comment.

Within the document, keep another place for relevant management’s review and approval of the change.

With this, you could have your change requests documented for future reference.