Why do RPA projects fail?

RPA projects usually fail not because of the software itself, but because of choices made beforehand and management afterwards. The wrong process is chosen, exceptions are not worked out, nobody monitors or owns the robot, and the saving is calculated on gross hours. Such causes can usually be recognised before the start. Many can be prevented with simple agreements.

What "failing" means

A software robot (RPA, robotic process automation) is software that takes over an employee's actions on screen: logging in, looking up data, filling in fields. It is not an industrial robot and does not control machines or PLCs (machine controllers). A robot project can fail in four ways:

• The robot never goes live, because the process turns out to be harder than expected.
• The robot runs, but stops so often that employees go back to doing the work themselves.
• The robot runs reliably, but delivers much less than promised.
• The robot is switched off after a year, because nobody maintains it.

How often does it go wrong?

The figure that is often quoted is that 30 to 50 per cent of initial RPA projects fail. It comes from a 2016 paper by the consultancy EY. It is an observation from EY's own consulting practice, mainly in the financial sector, not research with a described sample or method. EY also writes that it is often called in after a first attempt has failed, and it sells RPA advice itself. According to EY, the figure says nothing about the technology itself.

An academic article from 2024 mentions the same figure only "according to some sources". It does conclude that non-technical factors weigh more heavily than technical ones in RPA projects. So use the number as a signal, not as a measurement. The causes are more useful than the percentage.

The example: two versions of the same project

The ten causes at a glance

1. The wrong process

A robot suits work that occurs often, follows fixed rules and arrives digitally. It is a poor fit for work that occurs rarely, changes often or needs judgement every time. Yet companies sometimes choose the first process because someone is bothered by it, not because it is suitable. EY names choosing the wrong processes as one of the common mistakes.

Prevent it: measure before you choose. For a few weeks, count how often the work occurs, how many cases have an exception and how often the rules or screens changed recently. A process with a low volume, or with many exceptions that need interpretation case by case, is usually not a good candidate. Many exceptions with a fixed rule are not a problem. More signs are in when it is better not to automate a process.

2. Automating a bad process

A robot does exactly what the process prescribes, including the unnecessary steps. If an order is now printed, signed off and scanned in again, you rebuild that detour in software. A double check that was once introduced after a single incident suddenly becomes a fixed step in the robot.

Prevent it: map the process first, step by step, with the people who do the work. For each step, ask why it exists. Remove what adds nothing and make the rest unambiguous. Sometimes the process is then so simple that a standard function of the ERP is enough.

3. Exceptions underestimated

The normal order is quick to build. The work is in the exceptions: a customer who uses their own item numbers, an order split across two emails, a correction to an earlier order, an order for a drawing revision that is no longer valid, a price that is slightly different. If you design only the normal order, you get a robot that keeps getting stuck in practice.

Prevent it: before you build, collect a good-sized set of real examples, for example a month of orders. Note every exception and its reason. For each type of exception, decide: does the robot handle it itself, does it go to an employee, or is it rejected? An exception that goes to an employee goes into a review queue with the reason attached. In UiPath, that can for example be a task in Action Center (the part of UiPath where an employee handles tasks): the robot waits until a person has handled the task and then continues.

4. Fragile screen automation

A robot that operates screens depends on those screens. An ERP update moves a field, a new message appears, a customer's portal gets a new layout. An employee adapts immediately. A robot stops, or clicks in the wrong place. Take extra care if the robot sees an application only as an image, for example through a remote desktop. Then it cannot recognise fields by their technical properties.

Prevent it:

• Use an integration (API) or an import function if the system offers one. An integration is a fixed entry point for software and changes less often than a screen. The trade-off is explained in RPA or API integration: which is the best choice?
• Have the robot check that the right screen is there before it does anything. In UiPath, the Retry Scope activity repeats a set of steps until a condition is true, for example until a field is visible.
• Agree with IT or the supplier that you hear in advance when an update is coming. Test the robot after every major update, before it works with real data again.

5. No error handling or monitoring

A robot without monitoring (someone or something that watches the runs and reports problems) often stops without anyone noticing. You only notice when a customer calls about an order that was never created. A second pitfall is a robot that treats every error in the same way.

UiPath makes a useful distinction between two kinds of error. A technical error happens because an application does not respond or a field cannot be found. Retrying can help then. A business error happens because data is incomplete or incorrect, such as a phone number that is missing a digit. According to UiPath, retrying makes no sense then. Orchestrator, UiPath's management platform, does not retry such errors by default. Here a person has to act.

Prevent it:

• Retry technical errors a limited number of times. Send business errors straight to the review queue.
• Set up alerts. In Orchestrator, for example, you can subscribe to alerts when a job fails, or when a queue item (one case in the review queue) fails because of a technical or business error.
• Also check items that get stuck. A queue item that stays "In Progress" for about 24 hours without finishing gets the status Abandoned in Orchestrator.
• Use a safety net for unexpected errors, such as the Global Exception Handler in UiPath. It decides what the robot does then: retry, ignore the error or stop. A safety net does not replace well-thought-out handling for each step.
• Create a daily overview: how many cases were processed, how many are in the review queue, how many failed.

6. No owner in the organisation

A robot is often seen as something that belongs to IT. But IT does not know which price difference is acceptable or when an order must go through engineering first, and IT does not clear the review queue. Without an owner in the organisation, decisions are left waiting. EY names seeing RPA as an IT project, instead of an initiative of the organisation itself, as a common mistake. A new customer with its own order format does not get into the rules by itself, and during the holiday of the only employee who knows the review queue, it fills up.

Prevent it: appoint a process owner, someone from the department that does the work. This person decides on the rules, approves changes and tests them. Also appoint a technical administrator. Record who replaces them during illness and holidays.

7. Login details and security

A robot needs access to systems, sometimes to many systems. If it uses an employee's account, you cannot see afterwards who did what. If that employee changes their password, the robot stops. If the password is in the code or in an Excel file, anyone with access to that file can read it.

Prevent it:

• Give each robot its own account with only the permissions it needs. A robot that enters orders does not need to change bills of materials or delete customers.
• Store passwords in a vault, not in the code. In UiPath Orchestrator, login details are stored as credential assets. The robot only retrieves them during the work, with the Get Credential activity, which returns a username and a secure password. Orchestrator can also use external vaults, such as Azure Key Vault or HashiCorp Vault. According to UiPath, this is only possible with an Enterprise licence plan.
• Replace passwords at fixed times, and record who requested which password and when. OWASP, a non-profit organisation for software security, also advises this.
• Keep passwords and sensitive data out of the logs. At the most detailed log level (Verbose), UiPath also records the values of variables and arguments. So do not use that level by default in production.

8. No test environment

Without a test environment, you test in the live system. Then an error in the robot creates real orders, which may already reach the shop floor planning, or the ERP sends a confirmation to a real customer. For fear of this, there is often too little testing, and the problems only come to light after go-live.

Prevent it: ask your ERP supplier for a test environment and use a separate test mailbox. Test with a representative set of real cases, including the difficult ones. Test data with names and email addresses also falls under the privacy law, the GDPR (in Dutch: AVG), so do not use more than necessary. If a test environment is really not possible, build in a trial mode: the robot does everything except saving, and writes down what it would have done. For a few days, an employee compares that with their own work. Have the process owner approve the test, not only the developer.

9. No maintenance budget

A robot is not a one-off purchase. Systems get updates, customers change their forms, rules change, licences continue and someone has to follow up the alerts. If there is no budget for this, the first major failure is also the last. EY also names underestimating what is needed after go-live as a common mistake.

Prevent it: budget for support and maintenance per year, from the start. Make sure there is documentation, so that someone else can also change the robot. What maintenance involves and where the costs are is explained in what maintaining a software robot costs.

10. A saving calculated on gross hours

Many business cases count all the hours that the work takes now as a saving. That is not right. Exceptions stay manual work, and someone has to check the robot every day. On top of that, development, licences and maintenance are costs, not time saved.

Assumptions: 80 orders per working day, 4 minutes per order, 15 per cent exceptions, 15 minutes of checking per day and 230 working days per year.

In version A of the example, the company counts 1,227 hours. That is about 242 hours per year more than is actually freed up, even before the costs. After a year, the project seems disappointing, while the robot does what it should. The promise was too big. Also, time that is freed up only delivers something if you decide what that time is spent on. How to calculate the payback period honestly is explained in when automation pays off for a small business.

How to set up a robot project

The approach at the start determines much of the risk. Four common approaches side by side:

For a small or medium-sized company, one process as a pilot is usually the wisest start. Do choose a process with real exceptions, so that the pilot also shows the difficult side. How to introduce such a first process is explained in the guide to automating business processes.

Decision framework: questions before the start

Discuss these questions internally before you have a robot built. If you cannot answer one of them, you know where the risk is.

1. How often does the work occur, and how many cases have an exception? Is that measured or estimated?
2. Can someone explain the rules, including the exceptions?
3. Will the process or the system change within a year?
4. Does the system offer an integration or import, or only screens?
5. Who is the process owner, and who replaces that person?
6. Where do exceptions end up, and who handles them?
7. Who gets an alert when the robot stops, and how fast must they respond?
8. Which account does the robot use, and where are the passwords kept?
9. Where does testing take place?
10. Does the business case count the time actually freed up, and is maintenance budgeted?

The heaviest factors are the choice of process, the handling of exceptions and ownership. Technology can almost always be solved. A process without an owner cannot.

Outside help makes sense if you have no experience with robots yet, if the answers to questions 1 to 4 are uncertain, or if you want an independent view of the business case. A process analysis beforehand makes the risks visible. For robots that are already running, it is mainly about maintenance and support.

Limits of this approach

• Even a well-designed robot still depends on other systems. You cannot prevent a failure at the supplier of a portal, only notice it quickly.
• All these measures take time before the start. For a very small process, that can be more than it delivers. That is then a reason not to automate.
• Stopping after a pilot is not a failure. A pilot that shows that the process is unsuitable has done its job.

Conclusion

A failed robot project is rarely a surprise in hindsight. The signs are there beforehand: a process that nobody can explain, exceptions that nobody has counted, a robot without an owner and a saving that is too good to be true. If you answer those ten questions honestly before the start, you prevent most problems, or decide in time not to begin.

Sources

• UiPath Documentation: Business Exception vs Application Exception
• UiPath Documentation: Queue Item Statuses
• UiPath Documentation: Notifications (Orchestrator)
• UiPath Documentation: Logging Levels
• UiPath Documentation: Get Credential / Get Orchestrator Credential
• UiPath Documentation: Managing credential stores
• UiPath Documentation: Action types (Action Center)
• UiPath Documentation: Retry Scope
• UiPath Documentation: Global Exception Handler
• OWASP Cheat Sheet Series: Secrets Management
• EY (2016): Get ready for robots (pdf)
• Schlegel et al. (2024): How to conduct successful business process automation projects? Business Process Management Journal