In this article, The Case of Culture Mis-identity, cultural differences are under the spotlight. In this case, they turned an RPA implementation that should have lasted 6 weeks into 13 months. Find out about warning signs that things are going wrong.

“Hello hello…Holmes can you hear me…?” Watson shouted into empty space until, finally, the connection worked.

“Holmes, one of these days we have to investigate why this webex never works smoothly,” Watson sighed.

“I will add it to my long to do list, Watson, but first I want to hear about your 13 months RPA case,” said Holmes by way of greeting.

“Yes, finally we get to my part and I get to teach you Holmes!” responded a very excited Watson.

“So, first the facts: The RPA savings were agreed upon. The parties agreed that decisions such as IP and server location would be decided during the implementation phase. Many senior leaders on the client side attended all the conference calls so that questions could be answered and decisions could be made there and then. So, from a client perspective, they felt they were doing the right thing.

“Everything seemed OK. The calls weren’t very structured but the vendor didn’t highlight any problems so all seemed fine. But then, just before the due date, the deadline was pushed out by a month,” continued Watson.
“That can happen, but it happened again and again and again.” In all, the first RPA implementation took 13 months.

“Watson”, interrupted Holmes, “if I remember correctly, your client was already paying a lower price based on the RPA savings – even though it had not been implemented yet.”

Watson nodded her head. “That’s correct Holmes.”

“This must have cost the vendor a lot of money. I guess your client didn’t care too much about the delays?”

Watson nodded again. “You’re right Holmes, but after the umpteenth conference call with many senior leaders and no progression, this was becoming a costly exercise for the client, too, not to mention frustrating.”
“So your client got the project,” said Holmes.

“That’s right Holmes, great memory,” Watson responded. “My client took over and analyzed a number of problems.

“First of all, the project manager on the vendor’s side was Indian, and very young. There was no agenda, no clear structure, no proper project management. She wasn’t leading the project.” Watson took a sip of her coffee and continued.

“So those are the facts, but what few people realize are their implications. In India, hierarchy is very strong. Generally, when someone is higher in hierarchy, you follow their guidance. You don’t tell them what to do, give much pushback, or voice disagreement. In this case, many senior leaders from the client side were involved. Very likely, she was overwhelmed. Possibly, she was inexperienced about RPA, making her even more uncertain in speaking up and managing the project,” Watson explained.

“And your client didn’t recognize or anticipate this?” added Holmes.
“Spot on Holmes, accurately assessed as always,” responded Watson. “Secondly, all communication was by conference call. Conference calls are great, but they work differently when engaging with Indian professionals. Actually, Holmes, let me rephrase that: not only India, most Asian countries. Not all questions are asked on conference calls. Not all problems are raised. Not all negative feedback is given,” explained Watson. “So, western colleagues think everything is going fine, but sometimes it’s not.”

“Watson, this is very different from how many western professionals operate and communicate. I bet many find that frustrating!” said Holmes.

“Yes, Holmes, you’re absolutely right. When you don’t know if things are happening or you hear about problems at the last moment, frustration kicks in and professional trust is lost. But this is unnecessary. When you work with colleagues from other countries like India, it’s important to understand how they work and communicate and how to work together effectively. Once you know this, it’s not so difficult.”

Holmes looked at the ceiling, deep in thought, so Watson clarified: “You need to recognize the signs when things are going wrong. For example, when you can recognize the Indian ‘no’ in a ‘yes’, know how to get feedback about problems, and know the signs on conference calls and SCRUM meetings that things are going wrong, a lot of issues can be prevented. In this case, the RPA implementation could have been much faster.

“So when working with internal or vendor teams in India, knowing when to anticipate potential problems, recognize them as and when they are happening, and know how to resolve them, is the final success factor in the RPA journey,” said Holmes.

“Spot on Holmes,” said Watson.

“We make a good team Watson,” said Holmes as he put his thumbs up to the camera. “I loved our conversation, let’s have more soon. Enjoy your day in Amsterdam!”

“Great talking to you Holmes, enjoy your day in Bangalore!”.

The free Dr Watson – aka Ilse Kerling – summary:

• Assess who is leading the project on the Indian side and anticipate whether that could be a cultural mis-fit
• Be aware of the impact your hierarchy has on communication such as asking questions, voicing concerns a[missing text]

The post RPA (Part 3): The Case of Culture Mis-identity appeared first on Global Business Academy.

A series co-written by Ankur Bansal, Director Strategy and Transformation at Deloitte and Ilse Kerling, Founder Global Business Academy.

A continuation of: The Mystery of the Delayed RPA Caper...

A week later, Holmes and Watson met up in the Mumbai Cigar Club, just before Watson was flying back to Amsterdam. “Hello my dear Watson!” said Holmes. “That was an interesting client case that took me all around India. Too long a story, so let’s continue our RPA investigation. Where were we?”

“We agreed to discuss how you can recognize a good from a bad vendor, big fat promises and under deliveries, successful agreements and success factors,” reminded Watson. “So, Holmes, with RPA still being relatively new: How do you recognize a good from a bad vendor? Or an experienced from an inexperienced one? This seems like a project where parties can really overpromise or underestimate the project”.

“You’re absolutely right, Watson. A good vendor will look for a detailed discovery exercise. If you find a vendor who tells you that they can automate a process in x weeks without conducting a discovery exercise, you may well be in trouble,” said Holmes.

“Another thing to watch out for are big, fat promises. You will hear how RPA can bring enormous amounts of cost and FTE savings, efficiency gains, etc. This, my friend, needs to be assessed very carefully. You as a client need to challenge the vendor and understand their solution in detail. Remember, there are no easy rewards. If your process is very complex, fragmented, and spread across regions with multiple touch points – how on earth will you be able to automate such a process? At the very least it is going to take lot of time.”

“Hmm, that makes sense Holmes, but even companies with complex, fragmented processes want to implement RPA. Where do they start?” asked Watson.

“Look for early and easy successes if you want to make RPA work. Start small, with less complex and high volume processes that can deliver quick savings,” continued Holmes.

“The next best practice is to have a comprehensive agreement. Don’t trust verbatim commitments. Even in a good relationship with a vendor, it’s important to have a fully written contract,” said Holmes.

“I recognize this, Holmes,” said Watson. “My client is very happy about their vendor so they did not expect any issues”.

“Watson, I see this often,” Holmes interrupted. “The contract should not only cover the scope and activities but the vendor should be able to contractually put down the benefits he is going to deliver through RPA – and commit to it. It means that clients need to have the expertise to contract and negotiate with the vendors effectively.”

“That makes sense, Holmes, but I am sure it’s not only the vendors that need to commit contractually. When clients embark on a new project, they will be inexperienced too and make mistakes. What do they need to do to make the project run more smoothly?” asked Watson.

“That’s a good question, Watson. Indeed, clients have responsibilities, too. They need to ensure that IT has been involved at an early stage. It is the IT team that needs to ensure compatibility of solution and design of the RPA tool with the client’s environment. One of the risks that many companies do not plan for is they choose a tool and realize later that the integration of the tool to mainstream IT applications and infrastructure has not been planned. This takes a toll on the timelines. Remember, the RPA tool is going to access applications where the processes are operated upon. Hence, it is not only an integration concern but it can also be a security concern. This brings me to another point – Get your security checks done on time,” exclaimed Holmes.

“All of these are very important aspects of due diligence. Do not get into a contractual agreement unless all of these steps are verified and cleared by each department,” he added, finally finishing his case.

“So, my dear Watson, I would love to hear your investigation on how your client’s RPA journey turned from 6 weeks into 13 months?”

Watson looked at her watch and almost hit the roof of the Cigar Club. “I have to run and catch my flight!” she shouted. “Lets catch up by Web,” Holmes heard faintly as Watson was running out of the door. He smiled.

The free Sherlock Holmes – aka Ankur Bansal – summary:

1. Watch out for overpromising vendors who tell you that they can automate a process in x weeks without conducting a discovery exercise
2. Watch out for big, fat promises
3. Look for early and easy success
4. Have a comprehensive agreement where the vendor contractually puts down the benefits s/he is going to bring through RPA and commit to it
5. Involve IT at an early stage
6. Ensure compatibility of the solution to mainstream IT applications and infrastructure
7. Get your Security checks done on time

In our next article, The Case of Culture Mis-identity, we will look into how cultural differences turned an RPA implementation from 6 weeks into 13 months. Learn the warning signs that things are going wrong.

Ankur Bansal
Shared Services and Outsourcing Expert

The post RPA (Part 2): The Adventure of the RPA Derailment appeared first on Global Business Academy.

Holmes and Watson Unravel RPA Derailment

A few weeks ago, Ankur Bansal, Director Strategy and Transformation at Deloitte and Ilse Kerling, Founder Global Business Academy – 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. 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.

The post RPA (Part 1): The Mystery of the Delayed RPA Caper appeared first on Global Business Academy.