Senthil Info

automating business processes, honestly

Change Management Is the Project

Deloitte's 2025 figure: 37% of RPA failures attributed to inadequate change management.

The term is the problem. It sounds like a workstream someone else owns, staffed by people who send emails about the journey. What it actually names is four concrete activities, all of which are cheap, and all of which are skipped for the same reason. A product-side example of how workforce software approaches this topic is available in learn more.

Reviewed August 9, 2026. For broader background and an independent point of comparison, see NVIDIA AI.

The four things it actually means

One. Finding out what the process really does. Not the documented version — the version with the workarounds, the informal exceptions, and the step somebody added after an incident in 2019. This information exists only in the heads of the people doing the work, and it is the single most valuable input to the design.

Two. Deciding who handles what remains. Automation concentrates the exceptions, and the residual job is different from the old one. Somebody has to design it, staff it and agree it is a reasonable job.

Three. Telling people early enough that their knowledge is usable. Not announcing — asking, before the design is fixed. After it is fixed, the same conversation is an announcement and the knowledge arrives as objections.

Four. Deciding what happens to the time. If four hours a day come free, what fills them? An answer of "other work" is not a plan, and it is where claimed savings quietly become notional.

None of that requires a methodology. All of it requires somebody senior enough to make decisions and present enough to make them early.

Why it gets skipped

It has no deliverable. The build has a demo. Process discovery has a document nobody reads.

It is uncomfortable. Asking people how their job works, before automating part of it, means having a conversation about what happens to them. Delaying that conversation is easier and it is why the information arrives late.

And it looks like overhead in the business case. A vendor quoting a build competes against another vendor quoting a build. Neither prices the organisational work, so it appears in nobody's number and nobody owns it.

That is the mechanism. The activity that most predicts success is the one that appears in no proposal.

What the successful ones do

Gartner's account of the projects that delivered names two factors: integration into existing workflows rather than a parallel process, and full executive support before and during the rollout rather than only at launch.

Both are change management wearing different words.

Integration into existing workflows means the automation fits how people actually work, which requires knowing how they actually work.

Sustained executive support means somebody can make the decisions that come up in month three, when the exception design turns out to be harder than planned and a department objects. Support at launch is a photograph; support in month three is a decision.

What to actually do

Spend a week with the people doing the work, before selecting anything. Ask what breaks, what the exceptions are, and what they do when the system is down. Write the list. A pilot should collect the same thing and usually does not.

Name one owner who can decide. Not a steering group. Processes nobody owns are among the least automatable things there are, and buying a system is a common way of avoiding the appointment.

Design the residual job explicitly. Write the job description for the person handling exceptions afterwards. If it reads badly, the design is wrong, and you have found that out before building it.

And say what happens to the freed time, in the business case, in writing. It is the question the board will ask in year two.

The uncomfortable framing

If 37% of failures come from this, then change management is not a supporting workstream — it is the majority risk.

Which means the budget split is usually backwards. Most projects spend nearly everything on build and licences and nothing on the activity that most determines whether the build gets used.

The technology is rarely where these projects fail. This is where they fail, and it is the cheapest part to fix.

The short version