How Much of Your Time It Takes: The Client's Role in a Software Project

There is one line that never appears in a software quote: the hours you will have to put in. Not out of forgetfulness — they simply aren't hours the supplier bills, so nobody writes them down.

And yet they are what separates a project that finishes on time from one that drags on for months. I have seen technically harder projects close sooner, purely because there was someone on the other side who answered.

This article lays that time out: how much it is, when it is needed, and how to organise it without wrecking anyone's week.

Whoever builds the software knows the craft of building software. They don't know yours: they don't know that northern customers pay in 90 days and southern ones in 30, that one supplier has to be handled separately, that the delivery note is printed in three copies because one stays with the driver.

Exceptions are what make a management system, and exceptions live in the heads of the people doing the work, not in documents. The only way to get them out is to talk to those people. Without that time, the software gets built on the assumptions of whoever is writing it — and assumptions turn out wrong during testing, when fixing them costs ten times more.

At the start, to explain how you actually work. This is the densest moment: two or three meetings of a couple of hours, plus the time to dig out real examples — a typical order, a complicated invoice, the file you use today. It looks like a lot, and it is the time that saves all the rest.

During, to answer questions. Doubts will come up that nobody could have predicted: what happens if an item is out of stock, who can cancel an order that is already confirmed. They are short questions, but if they sit unanswered for three days the work sits with them. Budgeting half an hour a week, with someone who genuinely has the authority to decide, changes the rhythm of the project.

At testing, to try it properly. Not glancing at two screens and saying “looks nice”. Taking ten real cases from last week, including the two that went wrong, and running them through the new software. That is three or four hours, and they are the ones that prevent day-one surprises.

At launch, to stay close to the people using it. The first two weeks generate more questions than usual. If nobody inside the company has time to answer, people go back to the old method — and at that point the software exists but nobody uses it.

On a medium-sized project, the company's time is concentrated in a few weeks and then thins out. What matters most is that it is predictable: one fixed hour in the calendar every week is worth more than five hours scraped together at the last minute.

The single factor that shortens a project most is having one person acting as the bridge. They don't need to be technical, and they don't need to be the owner: they need to know the process, be reachable, and have a mandate to decide small things without calling a meeting.

When answers come from three different people instead, each saying something slightly different, the supplier stops and waits. That waiting is nobody's fault, and it still lands in the project calendar.

It happens, and it is legitimate: there are periods when a company cannot spare anyone. In that case there are two honest routes. The first is to push the start back by a few weeks, waiting for the right moment. The second is to shrink the project: doing half the things requires half the decisions, and a small first piece can be delivered even in a busy period — one of the reasons it pays to start from an MVP smaller than seems sensible.

What doesn't work is starting and hoping the time will appear along the way. It doesn't appear: it accumulates as delay, and in the end it costs both sides.