Automation and Change Management: How to Convert at the Goal Line

Doug Merrill
Written by:
Doug Merrill

Some of us would like to forget when our favorite sporting team was 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 significant business cases and have been delivered promptly. However, just as the solution is transitioned into production, many problems occur. These can include the Business team not liking the automation, the IT team requiring additional testing that was never considered, the solution’s underlying problem statement not being addressed, etc. These problems and many more could have been avoided or mitigated by introducing proper change management.


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 various 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 launching a new automation program or identifying issues within a current automation program. Before organizations launch a program or resolve these issues, it is critical to be culturally and logistically prepared.


Regarding culture, the program’s stakeholders (IT, business, and operations) must recognize and understand the need for change. We recommend beginning this process by conducting workshops to define the organization’s various challenges that have generated dissatisfaction with the status quo. These challenges will act as the forces of change. Once there is agreement on the challenges, 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 adopting 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?
  • Given the change effort, what is the expected impact on people, processes, and technology?
  • 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 of resolving the challenge, it should be deprioritized.


2. Design a realistic implementation plan

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

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


  1. Goals – What will the change accomplish? How does it align with the organization’s broader strategic vision and objectives?
  2. Key Performance Indicators (KPIs) – How will success be measured? What actual and expected results will be compared?
  3. Stakeholders – Who will own the change? Who will implement the change and perform the required maintenance?
  4. 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 initiative’s goals. This involves educating stakeholders on the automated solution and what it will deliver. It also involves identifying new skills and behaviors required to embed the new change. This often includes upskilling and demonstration sessions throughout implementation, where business users would be walked through the change, 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. 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 automation is that the business reverts to the old ways of doing things. So, to prevent backsliding, it is critical for those implementing the solution to hold regular touchpoints post-implementation with the business to answer questions and make required enhancements as needed.


5. Monitor results

The results are monitored once the change is implemented and embedded to ensure the new process is 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 of the automation (e.g., exception handling, business contacts, links to artifacts, 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 and strategy should be articulated early to ensure the subsequent frameworks, methodologies, and deliverables align with the program’s 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 articulated. Once roles are defined, training plans are developed to ensure each person placed into a role can develop the skills necessary to succeed.


Finally, a Governance Framework and Change Management functions, including a communication strategy for all stakeholders that 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 decision-makers to adopt and expand automation programs can be difficult. In our experience helping organizations to ‘course-correct’ their automation programs, we have identified several pitfalls that 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 adequate buy-in and adoption of automation.


If you are facing some setbacks in generating buy-in and adoption and need some advice, contact us here or reach out via email at


Written by:
Doug Merrill