The project is late. Should we simply change vendors?

The cost of switching is routinely underestimated. A new team has to understand the existing code and data structures from scratch, the project makes no forward progress during that period, and the handover itself adds time on top. Unless communication has broken down, progress is being concealed, or quality is clearly unacceptable, the more practical move is to hold a single alignment meeting first: establish whether the delay comes from shifting requirements, waiting on decisions, external dependencies, or the estimate itself, and only then decide whether to adjust scope, adjust the schedule, or genuinely replace the team.

What can the client side do to actually reduce the chance of delay?

Three things help most. First, appoint a single decision-maker so the vendor is not waiting between conflicting opinions from several managers. Second, put a clear deadline on every outstanding question and agree in advance what happens if it is missed. Third, accept that when requirements change, schedule and scope have to be re-estimated rather than held to the original date. Anything you are supplying — content, account credentials, documentation for systems you already run — should also be ready before the project starts.

Why is the timeline given in a quote so often missed?

Because estimates rest on assumptions that may not hold: that requirements will stop changing, that feedback will arrive on time, that third-party documentation is accurate, and that integration will work the first time. If any one of those fails, the date moves. The more reliable approach is to break the estimate down into small verifiable items, state the assumptions attached to the uncertain parts, leave buffer around integration and testing, and recalibrate at the end of each phase — rather than issuing a single date on day one that is expected to hold until the project closes.

Why Software Projects Run Late: Causes and Fixes

“You said three months. We are in month five and still testing.”

Some version of that sentence appears in almost every late software project. The first instinct is to assume the vendor is inefficient. Look more closely, though, and the time is rarely consumed by writing code. It goes into requirements that keep moving, waiting for decisions, external systems that refuse to cooperate, and integration and testing that were badly underestimated.

The four root causes of delay

One: requirements keep changing, but the schedule does not

This is the most common cause and the hardest to see. Each individual request — adding one small feature while you are in there, adjusting one field — looks minor. But a change ripples into the design, the data structure, existing tests, and every related page.

The problem is not that requirements change; requirements always change. The problem is that the change is not treated as a formal event: nobody re-estimates the effort, nobody adjusts the schedule, and nothing else is traded away. Accumulate enough of those and the delivery date became impossible some time ago — it just has not been said out loud.

The workable fix is a lightweight change process: every addition or modification goes through three steps — assess the impact, decide whether to do it, then adjust the schedule or drop something else. For how to write requirements and manage changes to them, see How to Write Software Requirements.

Two: time lost waiting for decisions

Development throws up a constant stream of questions only the client can settle: whether to keep this step in the flow, which version of the copy to use, how to handle exceptions to a promotion rule.

If there is more than one decision-maker, if they disagree, or if the contact person has to escalate through several layers, the waiting time on each question multiplies. Engineers do not necessarily stop working during that period, but they move to something else and come back later — and context switching has a cost of its own, quite apart from the risk that half the work has already been built on the wrong assumption.

What the client side can do is clear: appoint one contact with real authority to decide, and attach explicit deadlines to outstanding questions.

Three: third-party dependencies nobody controls

The moment a project has to integrate with an external system — payments, logistics, invoicing, an ERP you already run, a government or platform interface — part of the schedule stops being in the development team’s hands.

Typical problems: a queue to get access to the other side’s test environment, documentation that does not match actual behavior, an activation process requiring paperwork and manual review, and faults that appear only in production. This risk cannot be eliminated, but it can be exposed early: run a minimal integration test at the start of the project rather than leaving the connection work until late. For risk assessment on integration projects, see the guide to system integration and API development.

Four: integration and testing are underestimated

Many schedules give almost all of their time to “development” and leave a short tail for testing and fixes. In reality, connecting the individual features together, running the full flow end to end, and clearing the defects that emerge is the hardest part of the whole project to estimate.

Also routinely omitted: data migration and verification, training, deployment and rollback procedures, and the back-and-forth of fixes during acceptance. All of these are real work, and leaving them off the schedule does not make them free. For how to structure the acceptance phase, see How Software Acceptance Works.

Estimation: how to be less wrong

Break large items into small verifiable ones. “Membership system, four weeks” cannot be verified. Estimating registration, login, password reset, profile management, and permission control separately makes the error visible.

Write the assumptions down. Every estimate rests on premises: that requirements will not change substantially, that feedback arrives within the agreed window, that third-party documentation is correct. Put those assumptions next to the schedule so that when one fails, both sides have a basis for discussing an adjustment.

Estimate in phases rather than all at once. The further out the work, the less accurate the estimate. The practical approach is to estimate the near phase in detail, give only a range for later phases, and recalibrate at the end of each one.

Make the buffer explicit instead of hiding it inside every item. Buffer should be a separate, visible block on the schedule whose purpose is to absorb surprises during integration and testing. Buried inside each task, it simply gets consumed by each task.

NETVANA works in two-week sprints with an operable demo at the end of each cycle, precisely so that gaps show up early: if actual output in the first two sprints falls short of what was expected, the remaining schedule should be recalibrated then and there rather than at the end. For the full set of phases, see the software development process.

Five things the client side can do

Practice	Why it works
Appoint one decision-maker	Removes the dead time spent waiting on several opinions
Prepare content and credentials before kickoff	Avoids finishing development with nothing to launch
Accept re-estimation when requirements change	Lets the schedule reflect the real workload
Involve actual users early	Surfaces unworkable flows while they are cheap to fix
Set deadlines on outstanding responses	Turns back-and-forth into a predictable line item

There is one easily overlooked precondition behind all of these: whether anyone internally can take on the coordination work this project requires. If nobody can, the communication overhead of outsourcing will be far higher than expected — a trade-off compared in more detail in Outsourcing or Building an In-House Team.

The project is already late. Now what?

First, put the real situation on the table. The damaging part of a delay is not delivering late; it is finding out at the last possible moment that delivery will be late. A regular operable demo reflects true progress far better than a written status report.

Second, identify which category the cause falls into. A delay caused by changing requirements and a delay caused by underestimating the work are handled completely differently: the first is a conversation about scope and the change log, the second is a conversation about resources and the schedule.

Third, trade off between the three variables: scope, time, and resources. All three cannot stay fixed. The most common and most practical choice is to shrink the first release — move non-core features into a later phase and get the core flow live. That is the same logic behind building an MVP.

Two reactions to avoid. One is adding people. New team members need time to understand the project and will slow things down in the short term. The other is cutting testing. The time saved comes back after launch, doubled, in the form of defects and lost trust.

How to read a progress report instead of being reassured by a percentage

The easiest place for a progress report to mislead is a single overall completion figure. That number tends to sit near the finish line for a long time without moving — because what remains is exactly the hard integration and rework.

Three more reliable ways to look:

Look at something operable, not a written description. Whether you can actually open and use the result at the end of each cycle is the most honest progress indicator there is. When you can see it and click it, the gap cannot hide.

Look at the list of completed items, not the overall percentage. Ask for a list of features that have passed verification and will not be touched again. That list only grows, never retreats, which makes it more credible than any completion figure.

Look at how many unknowns remain. Every external system not yet connected, every rule not yet confirmed, every layout not yet decided is a schedule risk. Real progress is the number of unknowns going down.

If two cycles in a row end with “we did something else this time and will pick that up next time,” it usually means the deferred item has a genuine difficulty behind it and should be opened up for discussion immediately rather than pushed back again.

Different engagement models carry different delay risk

Fixed scope, fixed price. Easiest to control when the scope is genuinely clear, but any change has to go through a change process. The risk is that both sides avoid raising changes and push the original specification through to the end, producing something that does not fit the need.

Time and materials. Highly flexible and well suited to projects where requirements are still evolving. The risk is that without phase goals and a ceiling, the schedule extends indefinitely.

Phased engagement. Commission requirements and design first, then discuss development once those are confirmed. This puts the estimate on much firmer ground and is usually the most practical compromise.

Whichever model you use, the shared essential is that the contract states clearly how schedule and cost adjust when scope changes. Where that rule is vague, delay is close to inevitable.

Three common decisions that make a schedule worse

One: skipping testing to hit the launch date. The time saved returns after launch, doubled, as defects, customer complaints, and emergency fixes — and emergency fixes are usually lower quality, which feeds the cycle.

Two: taking shortcuts to hold the schedule. They genuinely are faster at the time, but they accumulate into extra cost on every future change. That is technical debt, and it is why so many projects find the second phase slower than the first.

Three: letting real users touch the system for the first time late in the project. If an unworkable flow only surfaces at that point, the cost of changing it is several times what it would have been at the design stage. Getting the people who will actually use the system in front of an operable version early is the cheapest insurance available.

Whether a schedule holds is mostly decided before the project starts: how specific the requirements are, who can make decisions, whether external dependencies were tested early, and whether buffer was written in.

If your project is running late, or you want the schedule and change process settled before work begins, talk to NETVANA about your project — we clarify scope and assumptions before discussing dates.

Further reading: to write requirements that do not keep reopening, see How to Write Software Requirements; to keep acceptance from turning into a standoff, see How Software Acceptance Works; and if you suspect old code is what is slowing you down, see Technical Debt Explained for Business Owners. For the handover terms that matter after a late project, see What Website Maintenance Actually Covers. For how the contract model shapes change requests and delays, see Fixed Price or Agile: Choosing a Contract Model; and for why weak regression testing keeps causing rework, see What Automated Testing Is, in Plain English; and for the release cadence that follows go-live, see Where a Product Goes After Launch. To avoid the delays covered here, see what clients should prepare before kickoff, see Software Project Kickoff Preparation.