Why the demo takes two weeks and the rest takes two months

Building something that works once, in front of people, on records you chose yourself, is now genuinely easy. Somebody in your team could manage it this weekend. I am not being dismissive about that. It is the source of the problem, because the demo is so cheap that it sets everybody's expectation for everything after it.

Everything after it is the work of turning that into something your business can run with nobody standing next to it.

The demo has no idea who you are

In a demonstration there is one user and that user can see everything. Nobody has asked whether the person in procurement should be able to reach the HR records through it, because in a demonstration there is no person in procurement. Deciding who may use it, and what each of them may see, is a conversation with your IT team and with whoever owns each set of records, and those conversations run on their own timetable rather than on yours.

It is also where you discover that the system you are connecting to has no way of telling the software who is asking. Then you are building that first, and it was not in anybody's estimate.

The demo cannot spend your money or break anything

Every answer costs money. In the demonstration you asked forty questions. In daily use two hundred people ask all day, and some of them wire their own spreadsheets up to ask on their behalf. There has to be a ceiling, and something that actually stops when the ceiling is reached rather than quietly carrying on.

If the system does things rather than only answering, the same applies to what it does. What is it allowed to change. How many records at once. What must it never touch. Software that can send email on your behalf can send four thousand of them before anybody notices, and I would rather write that limit down while everyone is calm.

Somebody will dispute an answer and you will need the record

One day a customer, an auditor or a member of your own staff will say the system told me this. You need to be able to look up what was asked, what came back, when, on whose behalf, and what the system then did about it. Adding that afterwards is miserable, because the interesting week is always the one before you started keeping records.

These systems get worse quietly, so somebody has to watch and somebody has to own it

The world moves. Your products change, your documents change, and the model underneath gets updated by its provider without asking your permission. Accuracy slips, and the failure does not announce itself. You get a system that keeps answering confidently while becoming slowly less right, with everybody still trusting it.

So the tests you agreed at the start have to keep running on a schedule, and a named person has to be told when the score drops. Named, with hours in their week for it, not a committee. Where nothing on this list has an owner, none of it gets looked at, and the thing degrades over about a year while continuing to appear on slides as a success.

Why this is not padding

Look at the list again. Access control needs your IT team. Spending limits need finance. The record of what happened needs whoever answers to your auditors. Real inputs mean the document scanned at an angle, not the five clean ones from the demonstration. Every item involves a different part of your organisation and a decision only that part can make. That is where the calendar time goes, and very little of it is coding.

It is also why our estimate looks long next to a quote that covers the demonstration and stops. Both numbers are honest about different things. Ask any supplier which of the items above their price includes, and read the answer slowly.

There is a version of this you can run yourself for nothing. When the demo works, before anybody celebrates, sit down and write out what would have to be true for it to run for a month with nobody watching. That list is your real project plan. Send it to me and I will tell you which lines are two days and which are two months.