Robotic process automation (RPA) is quick and cheap to implement, so why do some organizations struggle to get the benefits they expect? Is it the technology, the way it’s implemented or internal obstacles that create problems? Some studies show that up to 50 percent of initial RPA projects fail, which seems disproportionately high for a technology as versatile and non-technical as RPA.

Some RPA programs get into trouble for unique reasons but, typically, the challenges are due to entirely predictable and avoidable reasons. The combined impact of multiple mistakes or misses can make diagnosis tricky. Regardless, when an RPA initiative falls short, value is eroded, and the organization fails to achieve the full impact it was expecting.

What does a failed project look like? Assuming a business leader asks for a business case to get an organization going on its RPA journey, the most-common “trap” is underestimating the effort required to build enterprise-grade automations that can effectively handle exceptions and be easily maintained. And a rose-tinted view on benefits can lead to a business case that no one can actually deliver.

Let’s not forget that RPA is still software that needs to be properly installed and tested. If it’s not, your initial automations may take weeks to go live as IT tries to resolve errors related to infrastructure, set-up or stability and developers have to rework their automations to match the new configuration. Configuring RPA software to deliver an effective automation relies on process experts identifying and thoroughly documenting exceptions and how to handle them. If the process contains too many exceptions, the development cost rises, impacting that business case once again.

In addition, if developers work in different ways across RPA programs, using different approaches to architect automations, define automation objects, label exceptions and handle errors, then maintenance costs can rise unexpectedly. Developers need direction and support from an RPA Center of Excellence (CoE) that sets enterprise-wide standards and disseminates best practices. If the CoE doesn’t have the right structure or skills, progress will be slower than hoped for – and may even fail to scale beyond launch.

Above all, organizations must not forget that RPA is a change program. Change needs to happens at three levels:

• Within business functions: Many organizations don’t have an automation group working in the business. Establishing an RPA CoE is a key change for which other functions must create room. Business leaders must make peace with how automation will affect their ability to deliver their plans and be in control.

• Within an operational area: Delivering a single automation into a process requires a new project approach – one that calls for collaboration between process experts and frontline staff who may regard RPA as a threat to their jobs. Having a digital worker as part of an existing workflow may mean making changes to what certain human workers do on a daily basis to ensure work still flows smoothly.

• Across the whole operation: Few organizations automate only a single process. Most RPA implementations are part of a wider automation strategy that can lead to significant changes to the ways people work and even to the entire operating model. Individuals and teams need a clear vision of the potential change from the outset, so they understand in advance where things are going and how their role can help drive success. Just like in outsourcing, capturing detailed process knowledge is key for automation success. Organizations need to create a plan that outlines who to retain and for what duration.

Implementing RPA isn’t hard, but doing it right isn’t easy either. ISG has been helping enterprises get the most out of RPA since 2011, enabling them to maximize their ROI and ensure long-term success. To date, we’ve yet to have a single project fail, and we’ve turned around numerous failing projects that started without us.

Automation