Not all Robotic Process Automation (RPA) projects go smoothly.  In fact, sometimes it seems like bumpy roads can be the norm, rather than the exception.  How should you approach a troubled RPA project? What practices can be applied to turn a project around when things go sideways? I’d like to share an example with you.

Not long ago, we were engaged to revive a flailing RPA project. The existing vendor had not delivered (meaning deadlines were being missed, and code that seemed to work one day would break the next without warning) and we were asked if we could turn it around.

The beginning

Initially, we approached the situation as a technical challenge. There were a number of code quality issues that we felt would be resolved by migration to a strong overall design program. The customer had chosen UiPath as their RPA tool, so the first thing we did was migrate the implementation over to Cognizant’s UiPath Platforms methodology.

Platforms is a UiPath design pattern that we developed to provide design consistency, code modularity, and automated testing of components. This was the best tool for the job.

The problem

The first indication that there was an issue started with the Exception Rate. In RPA implementations, the Exception Rate is a measurement of the transactions that encounter Business Exceptions instead of being successfully processed. Initially we typically see Exception Rates around 20% as a rule of thumb. This normally decreases fairly quickly as the automation is enhanced to accommodate for these cases.

In this case however, the Exception Rate came in higher than normal at 30%. Normally, this would be somewhat minor and not a huge cause for concern, but under the circumstances, this customer was extremely upset. It turns out that originally they were told to expect a very small 2-4% rate of exceptions. This was not a realistic starting point and, as you can imagine, we were off to a rocky start.

But there was another problem as well that, combined with the Exception issue, threatened to throw the entire engagement into a tailspin. The customer was not able to provide us with development systems, only production systems. This meant that development had to be done on the production robots. These robots were slated to run 20 hours per day, which left only 4 hours a day when the robots could be used to address the issues that were causing the Exception issues. To add insult to injury, the robots were taken down for those 4 hours because the production systems that the robots were working with were undergoing routine maintenance. This made them unreliable during those times and that meant development work was nearly impossible.

The real problem

RPA implementation team and the business teamHow could we turn this around? The first step was the realization that the technical problems we were seeing were not the root problem. After a bit of sleuthing, we determined that the real  problem was a communication issue between the RPA implementation team and the business team:

  1. The Exception Rate issue was only a problem because the customer expected an unrealistically low Exception Rate. They were not expecting a typical rate of exceptions in their initial release. Had the customer understood that the rate would start off higher and then quickly taper down, they would have been able to plan accordingly and this would not have been an issue.
  2. The customer did not communicate effectively to us that we would be losing our development systems once we went to production. This meant that we were not in a position to either set appropriate expectations about issue resolutions or push back on the disappearance of those resources.

With the technical problems morphing into communication problems, we still found ourselves in a situation that could go South.

The solution

Fortunately, although communication problems are sometimes difficult to diagnose, they are relatively simple to fix.  Here are the communication principles that we have developed to ensure success in our RPA engagements:

  • Plan skeptically: Avoid overselling and remember that the benefits start slow and get better over time in a properly-run project.
  • Define and agree on metrics in advance: Everyone must be on the same page when it comes to business outcomes for the project.
  • Set expectations for metrics and time frames: Agree in advance on these issues, and have a written plan.
  • Regular reporting: A regular reporting cadence is important.
  • Single Points of contact, with escalation predefined: Someone needs to be the Skipper.

In the case study above, it worked out to have a happy ending. But, we might have saved time and trouble had we gone in from day one with the realization that there might be a communications problem. How do your projects fare on this scale?  Is the appropriate level of discipline present?

Let me know what you think below.

Shaun Dawson

Shaun Dawson

Shaun Dawson runs Cognizant's Global Center of Excellence for Intelligent Process Automation, which includes RPA. He has over 20 years of experience... Read more

  • Jose Ordinas

    Realistic planning is a key factor in ensuring satisfaction. Any time I see a Charter for an Robot which claims 100% automation even for relatively small processes (calling them a process is being generous) I challenge it hard… My sense is that there is over-optimism, and the risk is that the design does not appropriately incorporate the right escape valves should things happen (and we all know they will.)
    Glad you were able to turn this engagement around.

  • David Eddy

    How refreshing! An RPA article written by someone who has hands-on experience and can speak to actual implementation use cases. A welcome departure from the many RPA word salad posts. The observation about how exceptions typically decline, flatten and stabilize brought to mind machine learning. From what I’ve seen, that technology presents a similar challenge to the exception issue discussed here. Namely, how to create a test plan that accurately compensates for the fact that outcomes will “fail” – likely at a high rate – until the robot has been in production long enough to “learn” and up its game.

  • Prashant Mhatre

    Thanks Shaun. Very nice article that outlays the practical challenges, typical projects land up in during the end to end cycle. Over-selling is a typical phenomenon that starts with rewards and ends with punishment.Setting the right expectations, keeping the customer regularly informed about the progress and any challenges before he finds out, will help you manage the difficult problems, else even the trivial one’s can get escalated and leave a bad taste for the customer.