A new project kicks off with a launch date on the calendar. In the opening meeting everyone agrees the schedule is reasonable. Three weeks before the date, it turns out that the payments screen depends on an external vendor who has not yet granted access to a test environment, and that the product manager and the CEO understand "real-time reports" differently. The date moves, and by the time anyone calls it a "delay," it has already moved four times.
Almost anyone who has managed development knows this scenario. The delay is usually determined long before the first line of code is written.
The Delay Is Born in the Weeks Before the Code
A project that starts without a clear spec almost always discovers the gaps midway through development, when every fix costs several times more. A developer who finds out in week six that a requirement can be read three different ways has to stop, ask, wait for an answer, and rework what was already done. Nobody included the waiting time in the estimate.
That is why the most profitable investment in a project is the time spent before development begins. A good spec does not guarantee that everything will run smoothly, but it surfaces the big questions while they are still cheap to answer.
Seven Recurring Causes
1. Requirements that everyone reads differently. A sentence like "the user can manage their orders" covers a day of work or a month, depending on who reads it. If you cannot write at least one testable acceptance criterion for it, the requirement is not finished.
2. Unchecked external dependencies. A payment provider, the client's CRM, a government or banking API. The time it takes to get access, keys, and approvals appears in no developer's estimate, and it can stand alone at weeks.
3. Decisions waiting on one person. When a developer needs an answer and the person who holds it is in meetings until Thursday, every question costs a working day. A project with twenty such questions loses weeks without anything officially "getting stuck."
4. Estimates given as a single number. "Six weeks" sounds decisive, but it hides a range. A mature estimate says what is likely, what the worst case is, and which knowns and unknowns separate the two.
5. Gradual scope growth. Each small request looks reasonable on its own. Together they add a whole project, and nobody explicitly decided that. Anyone who does not keep an "in and out" list finds out after the fact.
6. Testing at the end. When QA starts only after development is "done," every bug it finds goes back to a developer who has already moved on to something else. That loop travels between teams and keeps getting longer.
7. Everything in version one. The team tries to build the full product rather than the version that teaches something. A well-defined MVP reduces risk because it brings real answers early.
In many projects the same pattern repeats: the team starts writing code, and midway it turns out that an interface to an external service behaves differently than assumed, or that one business definition is open to two interpretations. That is why we start every project with a list of dependencies and open questions, and close each one before it blocks work.
A Checklist Before You Start
An hour spent on this list in a kickoff meeting usually saves weeks later. It needs no special tools, only a shared document and a willingness to say "we don't know yet" when that is the case.
Before agreeing on a date, make sure you have an answer for each item:
- Every major feature has an acceptance criterion that can be tested, and not only a general description.
- All external dependencies are on one list, with a named owner on the other side and a date by which access is granted.
- Who decides what, and what response time is expected from them. If this is unclear, you will find out in week four.
- What is not in the first version, written down. The "no" list matters as much as the "yes" list.
- The estimate given as a range, with explicit assumptions. When an assumption proves wrong, you know exactly which part of the schedule is affected.
- A definition of "done": what has to happen for a task to count as closed, including testing.
Early Signs the Schedule Is in Trouble
There is no need to wait for the date to know. Several signs appear weeks before it:
- Tasks that stay "in progress" for more than a week with no clear explanation.
- Open questions to the same person that come back in every daily sync.
- The demo at the end of a stage shows screens, and not a complete flow running end to end.
- Estimates for upcoming features start to sound like "we'll see" instead of a number.
- The bug list grows faster than bugs get closed.
Any one of these alone can be noise. Two together are a reason to stop for an hour and ask what exactly is blocking, and who can solve it today.
What to Do When the Delay Has Already Happened
The common mistake is to add more developers. In a project that is late because of unclear requirements or an external dependency, adding people increases coordination cost and does not move the bottleneck. First identify what exactly is blocking, then decide whether the answer is a decision, access, a scope cut, or people.
Cutting scope is the most underrated tool. A feature that affects a tenth of users and costs three weeks of work can ship in the next release without hurting the launch.
Break the Project into Measurable Stages
A project planned as four continuous months discovers its problems in month four. A project divided into short stages, each with a deliverable that can be run and demonstrated, discovers them in week three. That is the difference between a one-week delay and a one-quarter delay.
It is also worth putting the riskiest part in the first stage, and not the most pleasant one. If the integration with the external vendor is what could sink the schedule, start there. That way you get an answer on whether it is possible at all while there is still room to maneuver.
How We Work on This
In projects we manage under the outsourcing model, the process starts with specification and requirements, and not with the team. Next comes a work plan with timelines we commit to, and only then do we assemble the team. Development itself happens in stages, starts with an MVP, and cuts time and features that are not needed, followed by QA, release, rollout, and operations.
At every stage there is a deliverable the client sees and approves, so a deviation from the plan is discovered while it is still small. When a change is required, we present it as a decision: what is added, what comes out, and what the effect on the date is. The decision stays with the client, but it is made with eyes open.
This order exists precisely because of the causes above. A work plan built on a weak spec is a forecast, and not a commitment.
The bottom line
Software delays are usually the result of postponed decisions, unchecked dependencies, and undefined requirements, and less a matter of the quality of the developers' work. Whoever invests the first weeks in bringing the hard questions into the open shortens the road more than any management tool can. The best estimate is the one that says honestly what is still unknown.
If you would prefer that someone take on the spec, the work plan, and the follow-through, you can read about the Outsourcing model.
