Senthil Info

automating business processes, honestly

Small Without Trivial

"Start small" is the standard advice and it is right. It also produces a specific failure: a first automation so easy that it teaches nothing, succeeds inevitably, and is then used to justify a second project of a completely different character.

Small and trivial are different. The distinction is worth being precise about, because the first project sets the expectations for everything after it. For a product-side reference related to workforce operations, Monitask also covers stealth monitoring software.

Why trivial first projects hurt

They succeed regardless. A scheduled report or a file move works, and the success carries no information about whether the organisation can do harder ones. For broader background and an independent point of comparison, see PwC AI.

They set the expectation of ease. Leadership that has seen one clean project assumes the next is similar, which is precisely the misaligned expectation that dominates failure reports.

They exercise none of the muscles. No exception design, no change management, no handover pressure, no maintenance. The organisational capabilities that determine later outcomes are untested.

And they consume the appetite. There is a limited budget of attention for this. Spending it on something that saves two hours a week means the interesting candidate arrives to a sponsor who has already spent their enthusiasm.

Four properties of a good first project

One. Real but bounded volume. Enough that the saving is noticeable — a day a week rather than an hour a month — and contained in one department.

Two. A genuine exception rate, around 5 to 15%. Low enough to work, high enough to force exception design. A first project at 2% exceptions teaches nothing about the residual job.

Three. One clear owner. Which is a precondition anyway, and on a first project it is also the thing you are testing: can this organisation give somebody the authority to decide.

Four. Reversible. If it fails, the manual path is still there and nothing external was affected. That is what makes it safe to attempt something with real content.

What to deliberately include

Even though it makes the project harder.

An exception path designed, not left over. Who handles them, how they are logged, how recurring ones feed back into the rules.

A handover, properly. The four documents and a two-week run with the builder sitting out. On a small project this costs a few days and it is where the organisation learns whether it can own these things.

And a measurement plan. Actuals against the business case at month nine — the habit is worth more than the first project's outcome.

What to deliberately exclude

Anything touching money directly, on a first attempt. Not because it cannot be done, but because the cost of a first-project mistake should be recoverable.

Anything spanning departments. The coordination overhead will dominate and you will learn about your organisation rather than about automation.

And anything on a system that is being replaced. You will build a bridge to a demolished building.

The honest metric for a first project

Not the saving.

Can we now answer four questions we could not answer before? What our real straight-through rate is. What exception handling actually costs. How long our organisation takes to make a decision during a project. And whether we can maintain something after the builder leaves.

A first project that produced those four answers and a modest saving is a success. One that produced a large saving and no answers has left you exactly where you started, with more confidence and no more capability.

The short version