READING TIME: 8 MINUTES
As I’ve already written a few key things about how to build RPA robots properly, it’d be just fair from me to write something about how your RPA projects might eventually fail, so you could make preventive steps when you see the patterns of failure, before it’s too late.
Failing to combine Business Requirements with Technology
The most critical part before the development starts is that at least one person has to understand the requirements that are coming from the business and has to be able to combine those requirements with the technology that is available for the development.
It is a very bad setup, when Business Analysts only understand the so-called “business part” of the projects, and developers are only capable of formulating the “technology part” of the solution, without having any bridges between the two parts.
Wherever I’ve seen this happening, this Bridge of Understanding was never let to be built, because developers have been provided very restricted access to the Business Experts, saying that only Business Analysts should deal with “translating Business to IT and vice versa”, acting like a quasi-barriers of communication instead of understanding-enablers, even though key messages have disappeared during the translations due to misunderstandings or ignorance.
The solution is very easy: at this point, don’t just talk about “being Agile”, but let the developers have frequent conversations with Business Experts, who were performing these processes before, and help them understanding the business aspects of every process steps.
Overpromising and Underdelivering
This is a classic mistake, when inaccurate estimations are made right at the beginning due to the demolished Bridge of Understandings, and/or not having stable processes to automate in the first place.
UiPath is providing a very insightful Solution Designer guidance on how to estimate the effort that is needed to build a robot, and the most important thing they’re highlighting is that it is very difficult to estimate the build effort of something that has (never been built before) so many uncertain components.
I especially “love”, when one of the three sins are committed:
- Making an estimation and setting up a scope, before someone with a high level of technical understanding would have seen the processes: having yes-men arranging scopes and deadlines is a setup to fail, regardless of the office politics.
- Estimations are made based on the number of steps, not on the complexity of those steps
- Abilities of the RPA developers and organisational bureaucracy are not factors when calculating the buffer-time: Building RPA robots is not a sprint, it’s a marathon for most of the organisations due to this.
The solution for these issues is not that easy: you need to have a Solution Designer, who has an understanding on both the business and the technological aspects of the RPA developments, and let him/her deal with the estimations and scoping.
Choosing the wrong tool
We have 3 leading RPA tools (Blue Prism, UiPath, and Automation Anywhere) on the market, but neither of them are ultimate solutions for your automation projects. Having only one of these tools are limiting the possibilities of implementation optimisation, but surely everything looks like a nail, if the only thing you have is a hammer, and a Swiss army knife cuts well, but you won’t start to maw the lawn with it.
The nature and the logistics of the process determine how advanced tool you need to choose for its automation. The systems used during the individual processes, the possible scalability needs, the process inputs’ and outputs’ complexity should be all part of the evaluation.
The solution for this is relatively hard: you need someone, who is aware of the capabilities of all (okay, at least two) of the above mentioned tools, and who is able to identify their suitability for the candidate-processes.
Sugarcoating
I’d say, from all of the points I’m listing in this article, this is causing most of the troubles during RPA developments. When it turns out that massive sugarcoating took place during the project, the consequences are usually disastrous.
Let’s imagine that the Process Discovery have failed, so your RPA developers don’t understand the process they need to automate. The deadline is not reasonable given the constantly emerging issues, but developers are not allowed to liaise with the Business-side for a fast resolution. The scope during the development has shifted, so the Solution Design can go into the dustbin, but this has only been announced with a two-weeks delay, when half of the product was already built. And the tool that has been chosen for automation turns out to be insufficient for the process that is about to be automated, so the developers are scripting crazily to develop additional functionalities that are missing from the RPA tool.
And when all of the above happened, somehow the project’s status is still GREEN, the deadline hasn’t moved even a day forward, even though it is obvious that it won’t be kept, but the communication goes like in the well-known meme below:
To be honest, to identify the sugarcoating from the outside of a project team is a challenge in itself. If you have a feeling that everything goes too good to be true, your gut-feeling is most probably right on this: someone is sugarcoating, so below the surface, something bad is already happening.
Well, isn’t it Agile enough to ask the developers halfway-though the deadline to show you the parts that are already working? If they can’t present you some progress, you can be pretty sure that someone is sugarcoating the sad facts.
It is very hard to solve the nature of the problem, because it is originated from fear. Unless building team-wide trust is a viable option, having someone who can objectively evaluate the progress on the projects is necessary.
Wanting to Sprint before Learning to Walk
RPA is not a field of immediate Big Wins. After choosing some tiny Proof of Concept processes, organisations tend to gain so much self-confidence that they immediately choose their most complex processes as automation candidates regardless of the fact that most of their developers have just learned how to use an RPA tool, and the logistics of building a robot (a.k.a. Delivery Methodology in Blue Prism) hasn’t been put in place yet.
Immediately implementing huge and buggy solutions will result in 3 main things:
- Low morale both on the Business and the RPA side due to having no success stories, but failures and a lot of time spent on reworking the solutions
- Bad foundations for future projects: as you haven’t started small, so the developers didn’t have time to experiment with the tools, and acquire the best practices. This results in medium competence and low understanding of the tool: a really bad combination.
- As reusability and structuring were not aspects (since they didn’t even know about the existence of such aspects) during the development of the robot components, your team will need to redevelop the components again for their future projects.
The solution for this is highly depending on whether you’ve already committed this mistake or not. If you haven’t done it yet: it’s very easy, you just have to make sure to start small. If you’ve already made the mistake: you need to take two steps back, put the Methodology in place, train up your RPA team, stabilise the robotic infrastructure that includes fixing the bugs in the legacy processes, and after you’ve done all these, you can roll out with new projects.
To Sum It Up
As you can see from the points above, an RPA projects don’t collapse because Agile Methodology hasn’t been used during the developments. Projects collapse because certain crucial elements of Agile are missing, what would make sense adding without even thinking of Agile in the first place. I’d worth an article to write about what to use in RPA in terms of Agile, and what to definitely avoid. Maybe next time…
Should you have run into challenges in automation or be about to start using RPA, drop us a message and let’s start a discussion!
Original article: https://www.linkedin.com/pulse/rpa-project-has-collapsed-why-balint-laszlo-papp/
