The complaint arrives in the same words almost every time. The developer is slow. Three months in, the thing that was supposed to take six weeks is not finished, nobody can say when it will be, and the meeting where you ask produces a list of reasons rather than a date.
Sometimes the supplier really is the problem. More often the work has been sitting still, waiting on a decision only you can make, and nobody has told you that in a sentence you could act on. The two look identical from where you sit, and they have opposite fixes: one is solved by changing supplier, the other is made worse by it. This is how to tell which one you have, in about an afternoon, without being technical.
Two different kinds of slow
Work is either being done or it is waiting. That sounds obvious and it is the whole diagnosis, because almost nobody measures the second one.
A task that takes ten working days to finish rarely contains ten days of work. It usually contains two or three days of building, and the rest is waiting: for a decision about what a page should say, for the logo in a usable format, for confirmation of which price list is current, for a reply from the payment provider, for you to look at something and say yes.
Nobody records those gaps because nobody is doing anything during them, and a supplier who has learned to keep the peace does not itemise them either. So the invoice says ten days, the calendar says three weeks, and you conclude that the building is slow.
There is a third bucket and it is the expensive one: work that was built, then redone because what it was supposed to do changed afterwards. That is not slowness. It is rework, and rework is almost always a brief problem wearing a delivery problem’s clothes.
The measurement that takes an afternoon
You do not need a tool. You need the last two months of messages between your side and theirs, and three counts.
Count the clarification cycles. How many times did they ask a question before they could continue, and how long did each answer take to arrive? Go through the thread and write down two numbers per question: the day it was asked and the day it was answered. The total is the part of the schedule you own.
Count the reversals. How many things were built and then changed, where the change came from your side rather than from a defect? Not fixes. Changes. A page approved and then restructured, a field added after the form was finished, a decision about who the site is for that moved in month two.
Count the open decisions. Right now, today, how many questions are sitting with someone on your side, unanswered? Most owners are surprised by this number, because each one individually felt small.
Read the three together. Long answer times and a high reversal count mean the brief is the bottleneck, whatever else is also true. Short answer times, few reversals and a schedule that still slips mean the problem is on the supplier’s side and you now have evidence rather than a feeling.
What a brief has to contain before anyone can estimate it
A brief generates clarification cycles when it describes a thing rather than a job. A modern website with five pages is a thing. What the developer needs is the job: who is supposed to do what, and how anyone will know it worked.
The UK government’s service manual publishes the format its own teams use, and it is worth copying because it forces the missing half into the open: every requirement names an actor, a need and a reason — as this person, I need to do this, so that this happens. Written that way, a requirement that nobody can justify collapses on the page rather than in month three.
The international standard for this, ISO/IEC/IEEE 29148, exists because the industry kept relearning it. You do not need to buy it. You need its premise: requirements are a deliverable with a quality of their own, and they are yours, not your supplier’s.
Four things, in practice, that remove most clarification cycles before they happen. Who the page is for, in one sentence, per page. What the visitor is supposed to do next. Where each piece of content is coming from and who is writing it, by name. And what has to be connected to what — the payment provider, the booking system, the accounting file — with the account details and the person who controls each one already identified. That last one is where reading a proposal properly pays for itself, because a proposal that does not ask these questions has quietly made them your problem later.
Why the requirements defect is the expensive one
This is measurable and it has been measured for decades. A study prepared for the United States National Institute of Standards and Technology put the ratio starkly: a defect caught at the requirements stage costs one unit to repair, and the same defect found once the system is in operation costs several hundred times that. Work presented at INCOSE and archived by NASA found the same shape from a different direction: a requirements error costs three to eight times more to fix in design, and up to three orders of magnitude more in operation.
Those numbers come from aerospace and large software, and your website is neither. The ratio still holds, because the mechanism is the same: everything built on a wrong requirement has to be unbuilt. Change your mind about what a page is for in week two and you pay for an hour. Change it in week nine and you pay for the page, the pages linking to it, the content someone wrote, and the test that proved it worked.
This is also why “we will decide that later” is never free, and why a supplier who lets you defer decisions indefinitely is not being accommodating. They are accruing a bill.
The signals that it is the supplier
Your questions get answered quickly and your decisions are stable, and it is still late. Then look for these.
Estimates that never change shape. A supplier who says two weeks in week one and still says two weeks in week five is not estimating, they are reassuring. A real estimate moves as things are learned, and the movement gets explained.
No visible increments. If nothing has been shown to you in a form you could click since the project started, there is nothing to be late about, because there is nothing to see. DORA’s research programme defines lead time for changes as the time from a change being committed to it running in production, and the reason that metric matters to you is that a team which cannot ship a small thing quickly cannot ship a large thing at all.
Everything in flight at once. When five things are all ninety per cent done, nothing is finished and every one of them is accruing rework. Atlassian’s own description of the practice is blunt about the fix: limiting work in progress shortens cycle time, because the constraint forces the queue to empty before it refills.
What to change, on whichever side it turns out to be
If it is the brief, the fix is not a longer document. It is a shorter decision loop. Name one person who can answer a scope question without convening anyone, give them two working days as a standing limit, and write down what happens when that limit passes: the supplier proceeds on a stated assumption and you live with it. Then stop reversals at source by agreeing that anything approved is closed unless it is wrong, not unless someone has a better idea.
If it is the supplier, do not start by threatening the contract. Ask for one small thing, end to end, in one week, in front of you. Not a mockup. A working change, live. What comes back tells you more than any status meeting, and it costs a week rather than a rebuild. If it arrives, the problem was the way the work was organised and it is fixable. If it does not, you have learned that at the cheapest price available, and the tenfold spread between quotations starts to make sense in retrospect.
Either way, the number to watch afterwards is the one you started with: how long a question waits before it is answered. It is the cheapest predictor of a delivery date that anyone in this arrangement has, and it belongs to you. If the deeper problem is that nobody in the company can hold the technical side of these decisions, that is what a fractional CTO engagement is for, and the meeting where a decision gets made by whoever is loudest is the version of this that costs the most.
Frequently asked questions
Our supplier says the delay is our fault. Are they just deflecting?
Possibly, and the count settles it rather than the argument. Ask them for the list of questions they are waiting on, with the date each was asked. If that list is short and old, they are deflecting. If it is long and current, they are right and have communicated it badly, which is a real failing but a different one. A supplier who cannot produce the list at all is telling you they are not tracking their own blockers, which is its own answer.
We are paying a fixed price. Does the waiting time cost us anything?
It costs you the thing you are actually buying, which is the site being live. A fixed price protects the invoice, not the date. It also creates a quiet incentive on the other side: when your decisions are slow, your project stops being the profitable one, and it moves down the queue behind work that is moving. Nobody announces that. You observe it as a supplier who has become harder to reach.
How long should a small change actually take?
The number that matters is not how long it takes but whether it is predictable. A text change on a live page should be same-day and it should always be same-day. A new page should be days, not weeks. If small changes take as long as large ones, the site has been built in a way that makes everything a special case, and that is a build decision made earlier which is now costing you every month.
Should we hire someone internally to manage this instead?
Only if the volume justifies a salary, which for most companies of this size it does not. What the role actually requires is a few hours a week of someone who can answer scope questions without escalating and who reads a proposal for what it leaves out. That is a decision-making function, not a full-time job, and hiring a junior into it usually adds a relay rather than removing one.
We changed our minds a lot. Is that avoidable?
Changing your mind is not the problem; changing it about settled things is. Expect to learn something in every project and leave room for it deliberately — a named allowance of days, agreed at the start, that absorbs discoveries without reopening the schedule. What causes damage is the change that arrives with no allowance behind it, because it silently comes out of something else that was already promised.