Changing course in the middle of an implementation can be challenging. Your organization depends on the initial terms outlined at the outset of the process, so receiving a change request (CR) document from your software implementation (SI) partner can be confusing and frustrating if you don’t know what to expect.

At Canidium, our expert implementation teams deal with evolving project requirements, unexpected configuration challenges, or changing circumstances during every implementation. We manage all manner of CRs and know the good and bad sides of change requests during an implementation.

Leveraging this experience, we created this guide to explain how to manage a change request, including:

• What a change request is
• When you should expect a CR
• Problems you may encounter with a CR

What Is a Change Request

A change request (CR) is formal documentation outlining an alteration to your proposed solution implementation. When your software implementation (SI) partner sends you a CR, it tells you that the implementation will need to change to accommodate a new priority, timeline, cost, configuration challenge, or some other factor.  

There are a wide variety of reasons you might receive a CR. Every shift in the implementation process that deviates from the original Statement of Work (SOW) you and your software consultants signed requires a CR. 

Your software implementation partner will send you an initial document with the proposed changes. You can either agree to these changes and sign off on the new proposal or negotiate the alterations. The document is then thoroughly reviewed by internal stakeholders, including practice leads, sales, accounting, legal, and the PMO.

Once you and your SI partner agree to the terms of the CR, the proposed changes to the implementation process can begin. 

When You Should Expect a CR

Most implementations require at least one change request due to discovering new factors as the process goes on, so you should expect to receive a CR at some point. Changes to the original SOW are inevitable as your software consultants grapple with your specific design, integration, and configuration goals. Receiving a CR during an implementation indicates that your SI partner is thorough regarding communication and documentation, an invaluable asset in software implementation.

At Canidium, we break down the implementation process into specific phases: 

CRs usually occur during either the Define or Test phases of the process. You will sign the original SOW document before the Define phase commences. As your consultants hone in on your specific requirements during the first phase of the process, it's common to notice a few elements of the original agreement that need alteration. CRs during the Define phase help you and your consultant create a highly tailored plan for your solution's implementation, ultimately generating a better end product. 

During the Testing phase CRs document the alterations needed to resolve any issues with the initial system. Features you initially wanted during the define phase of the project may need to be clarified when you're testing the solution, or you may spot an issue that requires reconfiguration. Change requests document the resolution of these issues.

At Canidium, we encourage guided UAT so that these changes can be made quickly and in person. This helps keep projects on schedule. Read more about guided UAT here.

Common Problems With Change Requests

Change Requests are an inevitable part of any project implementation process. While they serve a necessary purpose, they can pose significant challenges and risks to the project's timeline, budget, and overall success. 

Recognizing the warning signs that CRs are becoming problematic is crucial for your SI partner and you as the client. In this section, we'll explore common problems associated with change requests and their potential impact on your project.

• Scope Creep: CRs frequently lead to expanded requirements beyond initial expectations, increasing the size of the project and resulting in scope creep. The additional components of the projects can, under certain circumstances, strain resources and timelines, requiring careful management. 
• Generating Buy-In: The biggest challenge you may face is communicating the change requirements to leadership or your internal implementation team. Cost increases or extended timelines may be challenging to communicate to stakeholders. However, building buy-in for the proposed changes to the project is crucial. 
• Timeline Disruptions: CRs often require schedule adjustments, extending the project's duration. Unexpected issues or necessary adjustments usually take additional time to rectify. A CR may change the initial implementation timeline.
• Licensing Agreement Conflicts: CRs can trigger conflicts with licensing agreements, particularly when proposing extensions or timeline adjustments. This issue primarily occurs if you must purchase licenses for separate sandbox, test, and production environments. If this issue occurs, consider exploring alternative licensing arrangements.
• Increased Costs: A change request may impact your organization's total investment costs for the SAP solution. This component can be one of the most frustrating aspects of change management during an implementation. However, weighing the long-term ROI of a more tailored or seamless solution is crucial versus the initial upfront cost of an adjusted implementation. 

Knowing What to Do with a CR

Knowing how to handle a challenging change request is crucial. Negotiating directly with your SI partner is a normal part of the change management process. You may also have established flexible internal expectations to accommodate project alterations. 

Either way, remember that the success of your implementation will have long-term implications. A timeline delay, cost increase, or other issue may be disruptive in the short term. Still, if it enables the production of a more finely tuned product, it is a worthwhile investment. 

Out-of-the-box solutions typically do not provide the same ROI as well-configured systems. The more closely your software consultants can adjust the system according to your preferences, the better your outcome. The solutions architects and software engineers on your SI partner's team will be able to create a more tailored and productive solution when they incorporate your feedback along the way. They cannot correctly leverage their expertise on your behalf if they're entirely beholden to the original SOW document.

While it is entirely up to your team to handle a CR, it is also worth considering the proposed change's value and the potential project complications that accompany it.

Moving Forward After a Change Request

During the implementation of your solution, you are likely to receive at least one change request. Establishing this expectation ahead of time can help you, and by extension, your organization, navigate the process when it occurs.

A CR will not necessarily be problematic for your implementation. Sometimes, the change request is a simple administrative step to ensure proper documentation. However, it is not uncommon to experience issues with timelines, cost changes, scope creep, licensing agreements, and generating buy-in due to CRs. 

These issues can be disruptive but may also be necessary to produce a highly performative product. Your SI partner always tries to deliver the best solution possible for your specific requirements, which sometimes means adjusting the process. 

After you sign off on a change request, the implementation process will continue, ultimately leading to deployment. Your Canidium consultants will still be available to address any issues, updates, or other alterations you must make after using the solution. 

Are you considering changing SI partners before your project is finished? Read more about signs that you should switch SI partners and what that looks like.