30%-50% of initial RPA project fail.
Much is made in the press regarding the number of failed RPA Implementations, yet every day new articles appear to educate you on how to deliver a new successful x-Step approach to implementation, with so many "guaranteed roadmaps to success" out there, you imagine it would be impossible to go wrong! But that is clearly not the case.
Information on failures are not just hearsay, they are supported by a number of reputable sources such as EY's 2017 report "get ready for robots" which cited between 30% - 50% of initial RPA projects fail. HfS has cited a similar experience. Wherever you source your data, it's impossible to ignore that many organisations struggle when it comes to first implementing RPA despite the plethora of information freely available.
But are all failures a bad thing?
There are over 30 RPA vendors in the market right now and while I cannot profess to familiarity with them all, I am familiar with a wide range of vendor solutions and my main observation is this... under the surface each of these solutions are very different, providing different capabilities and different strengths and weaknesses.
As a consultant in this space, the first step in accelerating an automation journey is matching up the company needs with the vendor capabilities. This matching process generally provides priority order of fit which identifies the top 2 or 3 solutions that best fit the company needs.
A pilot stage follows to fine-tune your understanding, validate any assumptions, develop skills and begin to understand what is really possible.
However, many initial RPA projects do not follow this approach, skipping over the matching process and jumping right in with the first person - or loudest salesman - and run with that. You may be surprised to hear that I don't have a problem with this philosophy, giving RPA a try quickly is a good thing, so long as you are prepared to fail. Pause! And this is where things actually go wrong, while most people have probably heard the term fast-fail few really understand what it means, which leads me to my hypothesis!
Is it an RPA Failure or a Successful Proof an alternative is needed?
I believe that some of the so-called RPA failures could be reclassified as a pilot that has successfully proven that the RPA software being used was not a good fit for the business needs! This is an unfortunate, but still positive, outcome for a pilot that is testing for business fit.
There are plenty of reputable vendors out there with capabilities to fit every size, shape and budget and capable of meeting every business need. Spending the time up front to find the right fit is the first step on your journey to a successful RPA implementation.
I also accept there are alternative approaches, jumping in feet first to pilot a solution in order to evaluate fit is not an unreasonable approach. I'm just sitting in the camp that believes that it should not be called a failure if it proves to be the wrong solution for business needs. It is the first lesson learned on the journey of selection and it's time to re-evaluate the approach or move on to evaluate the next solution on your list.
The most likely gap in this scenario is not educating stakeholders in the approach being taken so RPA generally is perceived as the failure. The challenge of engagement and culture is one of the greatest hurdles to overcome and requires time and effort up front to ensure everyone understands the approach being applied. How many of the 30%-50% of RPA failures are actually failures of communication?
The take away
As a vendor agnostic consultant in this space we can provide an assessment of business needs in order to prioritise RPA vendor choices and help with stakeholder engagement and cultural adoption challenges. RPA isn't easy, but it doesn't have to be this hard either.