When I am asked to look at a project that has overrun, the cause is almost never the thing being built. It is the connection to something that was already there.
Somebody has to get data out of the finance package every night. Somebody has to read a file a government portal produces in its own format, on its own schedule. Somebody has to make the new system talk to an internal database with no documentation and no owner. None of it was in the estimate, because nobody knew it existed when the estimate was written.
Why these things hide
They hide because nobody thinks of them as systems. Ask a department head to list the systems they use and you will get the ERP, the email and possibly the CRM. You will not get the spreadsheet that decides which jobs go out tomorrow, because to the person who maintains it that is not a system. It is just how she does her job.
The other reason is ownership. The internal database was written by somebody who left in 2019. The finance package belongs to a vendor who charges for every call and answers in a week. Neither has an owner inside your organisation who can be asked to decide something, which is why the questions sit for a month while the invoice keeps running.
How to find them in week one
Do not ask what systems you have. You will get an answer taken off the org chart. Follow one real piece of work all the way through instead, from the first enquiry to the money arriving, sitting with the people who touch it, and write down every point where it stops.
A few questions do most of the work. What do you do on the last day of the month, which flushes out every export and every file that arrives by email. What would break if this particular person took three weeks off. And where do you type in something that already exists somewhere else, because every retyping is a join that was never built.
Then ask to see the inbox that receives automated files. There is always one, it usually belongs to somebody in finance, and what lands in it is a map of the connections your business already depends on.
What you will find
- An internal database with no documentation, no owner, and rules baked into it that nobody can explain.
- A finance or payroll package that only lets data out on its own schedule and format, and only if you buy the module that does it.
- A spreadsheet holding a department together, maintained by one person, with formulas nobody else has read.
- A customer or government portal with no way in except a person typing, so part of your process has to be designed around it.
- A system whose vendor charges for the connection and controls the timetable, so your project moves at their speed.
That last one is worth pricing carefully. Your supplier cannot commit to a date that depends on somebody else's support queue, and any supplier who does is guessing in front of you.
How to price it honestly
One number for the whole project, given before anybody has looked at the systems, is not a price. It is a bet, and you lose either way. If the supplier padded it you overpay for work that turned out to be easy. If they did not pad it they will be back, and the second conversation is always worse than the first.
What I would rather see, and what we do, is a short paid piece of work at the start whose only output is the list. What has to be connected, who owns it, whether a way in exists at all, and which of those has been confirmed rather than assumed. After that, a fixed price for the parts that are understood and a separate line for each connection, with a range and the reason for it.
The reason is nearly always the same. It is not how hard the work is. It is whether there is a way in, and how long it takes to get a login.
The clause that saves the timeline
Most of the overrun here is waiting rather than working. Waiting for access. Waiting for a vendor to reply. Waiting for two departments to settle who is allowed to release the data, an argument that predates your project.
So put it in the contract. Name who in your organisation is responsible for getting each access, name the date it is needed by, and state what happens to the timeline and the price if it does not arrive. That page changes behaviour, because it turns a vaguely shared irritation into somebody's named task with a date on it.
Before you commission anything, spend a day walking one order through your own business. You will find at least one system you were not told about. If you would rather we did that walk with you, it is the first week of any engagement anyway, and the cheapest one.
Working through this on a live programme?
A 45-minute call with the engineer who would run the work. We will tell you whether AI is the answer, including when it is not.