Five sprints. Six stories. A working web application with a nine-stage production flow modelled, a dozen forms mapped, a database schema, a deployed portal behind a login.

Zero users.

Not “low adoption” — zero. Nobody at the client’s plant had ever entered a real record into it.

Every module ran on mock data, because the build was gated on a historical data export that had been promised for four consecutive sprints and never arrived. Each sprint the story rolled forward untouched. Each sprint the model got more detailed and the floor stayed exactly where it was.

The problem was not the client’s response time. The problem was the direction of the build.

What the correct-looking approach actually costs

The original direction was a total remake: study the documents, model the business, build the better system, hand it over.

That shape has exactly one validation point, and it is at the end. You infer a process from paper, build against the inference for months, and discover whether you were right at the moment it is most expensive to be wrong.

It also changes two things at once on the floor — the tool and the process. Ask someone to learn new software and a new way of working in the same week and you are not running a pilot, you are running an argument.

And it produces a model before it produces a user. Five sprints of document-derived modelling had produced a very good model. It had produced nobody who used anything.

The inversion

I stopped the remake and replaced it with one rule:

Study the SOP they run today. Build that. Improve it afterwards, with the person who does the job in the room.

Build the current process faithfully — including its inefficiencies, including the ones that exist only because it is paper and spreadsheets. Recognisability is what buys adoption. Someone who opens a screen and sees the form they already know will use it. Someone who opens a screen and sees a stranger’s better idea goes back to the spreadsheet.

That single reframe also dissolved the gate that had held the project for five sprints. If you build what they do now, you no longer need a historical export — the data accretes, structured, from switchover day.

Not all digitisation is equal

The difference is arithmetic, and it decides the whole engagement.

At the plant, floor operators fill in paper forms — a dozen of them, at stations, with gloves on. Putting a screen in front of that adds work. It would have been abandoned inside a week, and rightly.

Downstream of those forms, one quality-control staffer sits and re-types the paper logbooks into a spreadsheet template. Same numbers, second time, by hand.

That is double entry, and replacing it removes work. It is the only kind of floor digitisation that gets adopted, because on day one the person doing it does less than they did the day before.

So module one is not the system. Module one is one form, replacing one spreadsheet, for one named person.

The question no amount of data could answer

Reading a single page of the paper logbook decoded the whole transformation: the order quantity divided by a fixed 300 kg batch gives the number of batches; multiply through by the recipe and you get the totals weighed on the floor.

Which raised the question the project actually turned on. There were two possible models:

• the floor weighs the totals and the recipe is derived from them, or
• the recipe is standing and the floor multiplies it up.

The arithmetic is identical in both directions. Every number in every workbook we held is consistent with both readings. No quantity of data can separate them — and the answer decides whether module one is a recipe library or a totals-capture form. Those are two different products.

Only the person doing the job could settle it. She did, in one sentence: the recipe ratio is master.

That is the case for SOP-first in a single example. A remake would have picked one of the two, built it, and found out at handover.

Building it as-is, deliberately

Three disciplines came out of the reshape, and they are the transferable part:

Never improve silently during the build. Every improvement candidate goes on a list — a controlled vocabulary instead of the same ingredient typed four different ways; computing the batch count instead of asking for it. The list is real and it is growing. The users pick from it after they are using the thing, not before.

Compute what the person is currently computing. The goal is that she stops doing arithmetic, not that she does it on a screen. The form derives the batch count from the order quantity, derives the per-batch quantities from the master ratio, and stores each moisture reading in the unit the database wants while showing her the unit she writes.

Carry the shared key from module one. The batch and lot identifiers are modelled as first-class fields on day one, even though module one does not need them. They are the client’s own existing convention, not one I imposed. Skip that and every later module needs a migration before it can link back.

Adoption is a measurement, not a judgement

This is the discipline most pilots skip.

“Adopted” is not something I get to declare in a status update. The trigger to build module two is a number: N consecutive days of entries in the system with no fallback to the spreadsheet. Until that number is reached, module two does not start.

And the switchover is a parallel run — paper and screen together — never a hard cutover. You do not turn off a factory’s records on a Monday morning and hope.

What actually changed

Five sprints of the correct-looking approach produced a detailed model, a deployed portal, and no user.

One reframe produced a named user and co-designer, a transformation decoded and confirmed by the person who performs it, two business rules written into a register as entry-time validation, and a measurable trigger for what comes next.

The system I had modelled may still be the right system eventually. It was never going to get built by anyone who was not already using something.

Build the process they have. Earn the right to improve it.