Suppliers rarely say this out loud, because it sounds like blame-shifting. But after enough projects the pattern is hard to ignore: the ones that go well share client-side behaviours, and the ones that struggle share the absence of them.
Name one decision-maker
The most expensive thing on any project is a question waiting for an answer.
One person who can decide, is reachable, and has the authority to say yes without convening a committee. Design by consensus produces software nobody wanted and takes twice as long to not want it.
Own the content
Builds routinely finish on time and then sit waiting for copy, images, or a product export someone has to be chased for.
Content is work. Give it an owner and a date like any other deliverable. If it is not ready, say so early so the plan can absorb it rather than discovering it at launch.
Review weekly, not monthly
A month of feedback delivered at once produces rework at the worst possible moment and feels adversarial to both sides.
The same feedback given weekly is a small correction. This is the highest-leverage thing a client can do and it costs an hour.
Say what the problem is, not the solution
"Add a dropdown here" is a solution. "Users cannot find last month's orders" is a problem, and it may have a better answer than the dropdown.
Suppliers who only receive solutions build exactly what was asked for, which is not the same as what was needed.
Treat changes as trades
Scope will change — that is normal and usually healthy. What causes damage is changes arriving as additions rather than decisions.
- This goes in, that comes out.
- Or this goes in and the date moves.
- Or this goes in and the budget moves.
Any of those is fine. Pretending none of them is required is how a project ends up late, over budget and acrimonious.
Let the work be visible
Ask for something demonstrable every week or two, however rough. Not a status report — the actual thing.
A project where the first real demonstration is in month three is a project where nobody knows whether it is going well, including the people building it.
Say when something is wrong
Discomfort voiced in week two is a conversation. The same discomfort voiced in month three is a crisis, and by then options have closed.
Good suppliers would rather hear it early. The ones who would not are telling you something worth knowing.
If you are at the start of this, our brief builder covers the questions worth settling before anyone quotes, and why software projects run late covers what tends to go wrong.
What slows software projects down most on the client side?
Decisions waiting for an owner. A team blocked for a week on a question nobody is empowered to answer has lost a week, and the question was rarely hard. Naming one reachable decision-maker with real authority costs nothing and saves more time than any tooling or process change.
How often should we review work in progress?
Weekly, against something you can actually use rather than a status report. A month of feedback delivered at once produces rework at the worst possible moment and feels adversarial; the same feedback given weekly is a small correction. It is the highest-leverage hour a client spends.
Enjoyed this? Let's work together.
Start a project