A four-week project that takes ten weeks rarely lost six weeks to bad code. It lost them to waiting — for a decision, for an approval, for someone with the right login to send it over, for a reply to a question that sat in an inbox for four days. Development time and calendar time are two different clocks, and on most delayed projects, the gap between them is almost entirely time nobody was actually coding.
Decisions are the most common bottleneck
A developer who reaches a fork in the road — two reasonable ways to build a feature, each with different implications — has to stop and ask, because guessing wrong costs more time than asking does. If that question sits unanswered for a week because it needs sign-off from someone who's traveling, the whole project stalls behind it, even though the actual work left to do hasn't changed. Naming one person with the authority to answer these questions, and a maximum response time they've agreed to, removes this bottleneck before it appears.
Access delays cost more than they look like they should
A project that needs credentials for a payment processor, a domain registrar, or an existing system often can't proceed past a certain point without them — and those credentials frequently sit with a third party, an ex-employee, or someone who needs to be reminded twice. A week lost waiting for a password reset is functionally identical to a week lost to a coding problem, except it was entirely avoidable if access had been gathered before the project started rather than requested as each need arose.
Feedback latency compounds across a project
A round of feedback that takes three days to arrive instead of one doesn't just cost two days once — it costs two days at every single review point in the project, and most projects have several. A team that commits to a specific feedback turnaround at the outset, and treats it the way they'd treat a payment deadline, removes a source of delay that otherwise resurfaces at every milestone rather than just the first one.
What's actually the developer's responsibility
None of this excuses genuine development delays — underestimated complexity, discovered technical debt, or a developer simply running behind are real and are the delivery side's responsibility to manage and communicate honestly. But conflating a delay caused by an unanswered question with a delay caused by difficult code leads to the wrong fix being applied — more developer hours won't speed up a project that's actually waiting on a client-side decision, no matter how many are added.
Distinguishing the two matters
Naming which category a delay falls into, at the point it happens rather than at the postmortem, is what lets a project actually get back on schedule instead of everyone quietly agreeing to disagree about whose week it was.
This sits inside the same buy, build or configure conversation — a well-run build only stays on schedule if both sides are managing the clock that's actually running, not just the one measuring code.
Our software team sets out response-time expectations and access requirements before a project starts, so the weeks that would otherwise be lost to waiting simply don't happen.
