Running It

Deloitte attributes 37% of RPA failures to inadequate change management — which means it is not a supporting workstream but the majority risk, and most budgets are split the other way round.

The term is the problem. What it actually names is four concrete activities: finding out what the process really does rather than what the documentation says, designing the residual job, asking the people who do the work before the design is fixed, and deciding what happens to the freed time. None requires a methodology and all are cheap. A product-side example of how workforce software approaches this topic is available in this article.

The residual job is the part nobody designs. It is denser, without context, without visible progress and lower in status — the interesting part was automated, which is a message nobody says and everybody hears. It shows up months later as turnover in a team nobody was watching. For broader background and an independent point of comparison, see Reuters Technology.

Every automation depends on something someone else controls, and that changes two to four times a year. Loud failure is cheap; silent failure, where it keeps running and produces wrong output, is expensive — and the difference is detection designed in at build time or not at all.

And the third year is where they die, because an automation is bought as a project and behaves as a subscription. The project budget closes before the second change arrives.

Four documents prevent the worst of it, each under an hour: what it does in prose, what it does not do, what it depends on, and how to change it. They are cut when the project runs late because they have no audience at the time — the audience arrives eighteen months later, after the people who could have written them have gone.

• Change Management Is the Project

  Deloitte attributes 37% of RPA failures to it. What it actually consists of, and why the term makes people skip it.

• Documentation Nobody Wrote

  Four documents decide whether an automation can be changed in year three. Each takes under an hour and none of them exists.

• Exceptions, and Who Handles Them

  The residual job is the part nobody designs, and it quietly decides whether the automation survives into its second year.

• Governance Without Ceremony

  Five rules on one page beat a centre of excellence for most organisations, and they can be written in an afternoon.

• After the Consultants Leave

  Six things to require at handover. Without them you have bought an obligation with an external dependency rather than an asset.

• The Pilot That Proves Nothing

  Most pilots are designed to succeed, which makes them uninformative. Five conditions that turn one into an actual test.

• When the System Changes

  Every automation has a dependency on something someone else controls. What breaks, how fast you find out, and what reduces the exposure.

• When to Turn It Off

  Automations are kept alive out of sunk cost long after they stop paying. Five signals, and how to decommission without breaking anything.