Some of us would like to forget the times when our favorite sporting team were in the lead for most of the game, only to have their opponent steal the win at the last minute. Automation programs sometimes have this too, where solutions make it to the goal line but fail to convert.

As automation industry veterans, we frequently hear about automated solutions that have great business cases and have been delivered in a timely manner. However, just as the solution is transitioned into production, all sorts of problems begin to occur. These can include the Business team not ‘liking’ the automation, the IT team requiring additional testing that was never considered, the underlying problem statement not being addressed by the solution, etc. These problems, and many more, could have been avoided or mitigated by introducing proper Change Management throughout.

In this two-part blog series, we will outline an approach to properly inculcate change management within the context of automation (both Robotic Process Automation [RPA] and Intelligent Automation [IA]). In this first installment, we will focus on introducing an approach to change management and discuss what is required in the lead-up to launching a program. In Part two, we will focus on the change management required after the program has gone live and begins to scale.

Five-Step Approach to Change Management  

It is essential to work with a variety of internal stakeholders to ensure all aspects of change management are addressed and smoothly coordinated during the rollout of an automation initiative. Our change management framework consists of five (5) steps: 

1. Prepare stakeholders for change 

The change management process is typically triggered by the launch of a new automation program or by the identification of issues within a current automation program. Before organizations jump into launching a program or resolving these issues, it is critical to be prepared both culturally and logistically.  

In terms of culture, it is imperative that the program’s stakeholders (IT, business, and operations) recognize and understand the need for change. We recommend beginning this process by conducting workshops to define the various challenges facing the organization that have generated dissatisfaction with the status quo. These challenges will act as the forces of change. Once there is agreement on what the challenges are, buy-in from stakeholders (who will need to implement the change, remove friction, and maintain momentum) is established. In a subsequent section of this blog, we detail strategies for generating buy-in and adoption of process automation.

Regarding logistics, we recommend initial discussions with stakeholders where the following prioritization questions should be considered:  

• What would be required to address the challenges?  
• How much time and resources would be required to address the challenges?  
• What is the expected impact on people, process, and technology given the change effort?  
• What are the expected costs and benefits of the change?   
• What are the expected impacts of doing nothing?  

If the rough estimate of effort is deemed too high relative to the benefits from resolving the challenge, it should be deprioritized.  

2. Design a realistic implementation plan 

Once there is buy-in for the required change and the change is prioritized given expected costs and benefits, a realistic plan should be designed. This involves explaining to each of the stakeholders what the change is, why it is necessary, how it will be implemented, and what the impact will be to the current process/timeline. Since communication is a two-way feedback process, we suggest engaging stakeholders to illicit recommendations on how the change should be implemented, embedded, and managed. Ultimately, it is the business that will approve any change and two-way feedback is critical for that.

To best facilitate this two-way feedback process, the plan design should contain the following components:

• Goals – What will the change accomplish? How does it align to the organization’s broader strategic vision and objectives? 
• Key Performance Indicators (KPIs) – How will success be measured? What actual and expected results will be compared?  
• Stakeholders – Who will own the change? Who will implement the change and perform the required maintenance? 
• Scope – What specific tasks must be completed (by the implementors and the automation itself) for the automation to go live? 

3. Implement  the change 

In addition to configuring the automated solution as it has been designed, a critical aspect of implementation is empowering the business and other stakeholders to take the necessary steps to achieve the goals of the initiative. This involves educating stakeholders on what the automated solution is and what it will deliver. It also involves identifying new skills and behaviors that are required to embed the new change. This often includes some upskilling and demonstration sessions throughout implementation, where business users would be walked-through what the change is, why it is necessary, how to perform the ‘new’ process, and how to access reference materials and guides.

4. Embed the change

After preparing stakeholders for the new change, it is time to embed the change into systems, processes, and policies. It in addition to implementing the changes systemically, these changes are reinforced by rewarding new behaviors and achievements in alignment with the new changes. One of the biggest dangers to the success of the automation is that the business reverts to the old ways of doing things. So, to prevent the backsliding from occurring, it is critical for those implementing the solution to hold regular touchpoints post-implementation with the business to answer questions and to make required enhancements, as needed.

5. Monitor results 

Once the change is implemented and embedded, then results are monitored to ensure the new process is being performed correctly. This touches on continuous communication and engagement with the various stakeholders, providing training and support as needed, monitoring KPIs such as handling time and number of exceptions and explaining any deviations from expectations. In addition, when enhancements are deployed there is often a “Hypercare” period where the delivery team transitions work to the production support team. This transition should be facilitated through training and the production of an Operational Handbook that details all aspects of the daily running the automation (e.g., exception handling, business contacts, links to artefacts, etc.). A thorough post-implementation review should be completed to reflect on what went well and what could be improved for future implementations and change initiatives. 

Launching an Automation Program

From the onset of an automation program consideration should be given to what is required to achieve success and to enable the program to expand and grow. As a first step, an automation champion is typically designated to create a fit-for-purpose Operating Model and Governance Framework. At Reveal Group we call our service offering related to establishing an Operating Model, our Blueprint for Scale (BfS), which we tailor to meet each of our clients’ unique operating environments and their desired scale for the program.

A robust BfS comprises five capability components (depicted in the figure below) with the Govern component focusing on establishing capability within a Center of Excellence (COE) construct. A clear Vision & Strategy should be articulated early to ensure the subsequent frameworks, methodologies and deliverables are aligned to the program’s desired objectives.

From there, the Organization & People component outlines the roles required to meet the program objectives and to ensure all task accountabilities and responsibilities are clearly articulated. Once roles are defined, training plans are developed to ensure each person being placed into a role will be able to develop the skills necessary to be successful. Finally, a Governance Framework and Change Management functions, including communication strategy for all stakeholders which support the COE / Operating Model, should be introduced, and designed to evolve as the program scales. The figure below is an example of an Automation Governance Framework to support the flow of information between various program stakeholders.

Strategies for buy-in and adoption of process automation 

Convincing business leaders and decisions makers to adopt and expand automation programs can be a difficult task. In our experience helping organization to ‘course-correct’ their automation programs we have identified several pitfalls, which have slowed momentum and prevented programs from reaching their full potential. In the figure below, we conclude this blog installment with a non-exhaustive list of common pitfalls, along with some practical mitigation strategies to overcome each and ensure effective buy-in and adoption of automation. 

If you are facing some setbacks when it comes generating buy-in and adoption and need some advice, then we would love to hear from you. Contact us here or reach out to on email at [email protected]