Holmes and Watson Unravel RPA Derailment

A few weeks ago, Ankur Bansal and Ilse Kerling – aka Sherlock Holmes and Dr. Watson – met up for lunch. Sherlock had just visited a client in India who had recently embarked on a RPA journey. As he entered the board room, Sherlock could hear murmurs:

“Was it covered in the agreement?”

“Can we contractually penalize the supplier?"

“There we go!”, Sherlock said to himself. That was his first clue. 

In the meantime, Watson had been supporting a client in Amsterdam, whose RPA journey turned from 6 weeks into 13 months.

“There we go!”, Watson said to herself. Frustrated teams and deadlines that are pushed out again and again and again.

That was her first clue.

In both cases, the RPA implementation went horribly wrong. There were delays and extended timelines resulting in budget overshoot.

What clues can unravel the mystery of “why RPA implementations go wrong and who is to be blamed?” How to meet deadlines, operate within budget and ensure your operation moves swiftly?

“Well Holmes, what do you make of the project delays in my case?” asked Dr. Watson.

“Let me know the facts, Watson. You know I only rely on facts,” said Holmes.

“What we know so far is that the first RPA implementation was agreed to be delivered in 6 weeks, yet took 13 months. The client had anticipated it would take longer, as first-time agreements such as IP and server location had not been agreed on yet, but never in their wildest dreams did they think it would stretch to 13 months,” explained Watson.

“How was the timeline of 6 weeks finalized?” asked Holmes.

“That’s a good questions Sherlock. I only got involved once the client wanted to execute their work. But in this case, both vendor and client contractually agreed to lower the contract value by replacing headcount with RPA. Because the contract value was lowered immediately, my client wasn’t initially concerned about the delays. But, after the umpteenth conference call with senior leaders and the umpteenth deadline that wasn’t met, they realized it was costing them a lot of time, money and frustration. That’s when my client took over the project internally,” said Watson.

Then Watson switched gears. "I’d love to hear more about the pre-agreement stage in your case, Sherlock," she said. "If there is one person who knows all about it, it’s you. Enlighten me! What happened? What signals indicated it was all going wrong? What were the underlying problems? What are best practices? Then I’ll tell you all about the miscommunication that my client ran into."

“Well Watson. You see, best practices are nothing but a strong process of due diligence, before you get into a contractual agreement with the vendor," explained Holmes. "After all, it’s a binding agreement hence some effort should go into it."

“The first best practice is to understand that RPA automates a process “As Is” and does not change the process. In fact, it also excludes any exception in the series of activities that cannot be automated,” said Holmes.

He noticed that Watson had a blank look on her face, so he clarified.

“I mean activities where manual interpretation is required, dear Watson”, he expanded, smoke circling from his beloved pipe.

“Planning an RPA implementation requires a detailed assessment of the processes that need to be automated. This is called the Discovery exercise. This exercise is important to understand the complexity of the processes in order to determine the effort required for RPA implementation. Most often, lack of Discovery is a major cause for delay,” continued Holmes.

“That makes sense,” said Watson. “But this begs another question. What I really wonder about is this: Is RPA always the right choice? Is it sometimes not better to replace legacy systems instead of applying RPA?"

“Well, Watson. I think that replacing a legacy system and RPA have different objectives," said Holmes. "However, this can be a warning to organizations that are looking to adopt RPA. They should not expect RPA to fix processes or plug functional gaps in legacy systems. Replacing a legacy system with new state-of-the-art systems brings new features and functionalities that serve different purposes. RPA is simply to automate tasks,” continued Holmes.

"So I guess when teams are feeling the pain and pressure of 'speed to market', the pace of change required means a band-aid is necessary," said Watson. "If they wait for the legacy system to be upgraded or replaced they could become obsolete waiting."

"But if that is not the case, then replacing the legacy system has big advantages. Not necessarily cheaper, but more functionality,” she added.

“Spot on, Watson,” smiled Sherlock whilst he looked at his watch – and then rushed out of the door exclaiming … “I’m so sorry, dear Watson, I have to cut our conversation short. I have to investigate a new client case. Next time, we’ll discuss how you can recognize a good from a bad vendor, big fat promises and underdeliveries, successful agreements and success factors."

And with that, out of the door rushed Holmes, leaving Watson alone in the restaurant and a little astounded, which really, after all those years of knowing Holmes, she shouldn’t be.

The free Sherlock Holmes – aka Ankur Bansal – summary:

1. 1. Conduct a strong process of due diligence before you get into a contractual agreement
   2. Conduct a thorough Discovery exercise; a major cause of delay when not done well
   3. Assess why you want RPA versus replacing the legacy system

In the next installment, The Adventure of the RPA Derailment, Holmes and Watson discuss how to recognize a good from a bad vendor, big fat promises and under-deliveries, successful agreements, and success factors.

Read more from Ankur Bansal and Ilse Kerling in their SSON columns:

Smarter Outsourcing for Today's Enterprise – A. Bansal

Tools and Methodologies for Closing the Cultural Divide – I. Kerling