No time right now: what a custom project really asks of your team

"We don't have time right now" comes up in almost every first conversation. The short answer: the time a custom project really asks of your team is measured in hours, not weeks, and it concentrates on four specific moments. The rest of this article lists them, and how long each one takes.

The four moments when you are actually needed#

A custom project does not keep your team busy the whole way through. It asks for time at four moments, and no others:

• The audit, one to two days, spread over a week rather than blocked all at once: we watch the real work, we don't fill in a questionnaire.
• Validating the first block, before it gets built: one hour to confirm we understood the most costly problem correctly.
• Going live, once the first block is ready: a short training session, in small groups, not a whole day set aside.
• Monthly feedback, once the application is in use: what needs to change, reported by the people who use it every day.

What is never asked of you#

None of this looks like a classic IT project:

• no specification document for you to write yourself: the method that avoids it handles it differently;
• no weekly steering committee, and no internal project manager to appoint;
• no full week to clear: the time asked for fits into a few spread-out hours;
• no commitment to describe the whole scope before starting: we build block by block, which avoids most of the reasons a software project drifts.

You're starting from zero.

No: we start from what you already do, not from a blank page. That is exactly what keeps the audit short.

How much time, concretely#

Take a joinery business with eighteen people launching a project on tracking its quotes and worksites. The figures are a hypothesis, to show the order of magnitude.

Over the first six weeks, the owner will have spent a little under two days on the project, spread out, never two days in a row.

What changes with an application built for the business#

Once the first block is live, the time asked for does not grow with usage: it's the teams who gain time, not the other way round.

Concretely:

• a single point of contact is enough on the company side, not a committee;
• feedback lands inside the tool itself, not in a meeting report to read back;
• each following block is built on the same rhythm: a few hours of validation, not a new project scoped from scratch;
• the time saved day to day on what used to be done by hand far outweighs the time invested at the start, within the first weeks of use.

What not to do#

Two mistakes come up often, and neither is about a genuine lack of time.

The first: picking whoever is most available rather than whoever actually knows the problem. An audit run with someone who doesn't do the work daily produces a first block that misses its target.

The second: trying to clear a whole week "to be safe". The useful time in an audit is spent watching real work, not sitting through back-to-back meetings: a blocked-out week rarely holds more than the hours listed above.

The time a custom project asks for: the key takeaways#

The time genuinely asked of your team is measured in hours, concentrated on four specific moments: the audit, validating the first block, going live, and short monthly feedback. None of it looks like a classic IT project with its specification document and steering committee.

If "we don't have time" is the reason holding a project back at your company, the question to ask isn't "how long will it take", but "what exact hours does it need, and from whom": the answer is almost always shorter than feared.