The estimate covers the part everyone can see
When a team estimates a piece of software, they are estimating construction. How long to write the importer, the rules engine, the screens, the reports. Engineers are not wildly bad at that. Given a clear specification and a system they have seen, a competent team lands construction inside a range they can defend. The slip does not come from there. It comes from the four things nobody put a number on: getting access to the data and the environments, getting decisions made, connecting to systems whose owners have their own priorities, and getting somebody to agree the work is finished. Those four consume most of the calendar on most projects, and they appear in almost no estimate.
Access. A vendor cannot build against a database they cannot read. The gap between "you'll have credentials Monday" and a working connection from the vendor's laptop is measured in weeks more often than days, because it usually crosses a security review, a firewall change, a license seat, and one person on vacation. Two to six weeks is the ordinary range. It is not anybody's fault and it is almost never in the plan.
Decisions. Every build produces questions the specification did not answer. What happens to a record with two owners. Which of the three revenue definitions the report uses. Whether a partial match is a match. Each of those is a five-minute conversation with the right person and a three-week wait for the wrong one. A project with no named decider accumulates these until they become a rewrite.
Integration. Anything that touches a system you do not control is a schedule item owned by somebody who does not report to you and has not agreed to your date. Payment processors, identity providers, an ERP with a customization from 2014, a partner's API with documentation that no longer matches the behavior. The build is a week; the negotiation about the sandbox account is a month.
Acceptance. If "done" was never written down in a form somebody can test, done is whenever the loudest reviewer stops objecting. That is not a date. It is a mood.
You are probably here because
- The status has said ninety percent complete for five weeks
- Nobody can tell you what is left, only what is nearly done
- The date moved once by two weeks and then again by six
- You are being asked to approve more budget for the same scope and you cannot tell whether that is honest
All four are downstream of the same thing: the schedule was built out of construction estimates and the calendar is being spent on everything else.
Where the weeks actually go
The table below is our working model for a three-to-six month build with one integration and a real data dependency. It is a starting point for a conversation, not a measurement of your project. The number that matters is not the percentage. It is that four of the six rows are outside the vendor's control, which tells you where to spend your own attention.
| Where the calendar goes | Typical share | Who controls it | What compresses it |
|---|---|---|---|
| Writing and testing the software | 35–50% | The vendor | Fewer features, not more people |
| Getting access to data and environments | 10–20% | Your IT and security | Starting the request before the contract is signed |
| Waiting on decisions | 5–15% | You | One named decider with a 48-hour service level |
| Integrating with systems you do not own | 10–25% | A third party | Proving the connection in week one, not week ten |
| Review, acceptance and rework | 10–20% | Shared | Written, testable acceptance criteria up front |
| Everything unforeseen | 5–15% | Nobody | Contingency you actually budgeted |
Read that table once more with the question a good sponsor asks: if I want this six weeks earlier, where do I get the six weeks? Almost never from the first row. Adding engineers to construction is the least effective lever available and, past a certain point, a negative one. The six weeks come from row two started earlier, row three answered faster, and row four attempted sooner.
Three causes, and only one of them is about engineers
Scope that was never actually fixed. Not scope creep in the cartoon sense, where somebody demands a new feature. The quieter version: a requirement everyone read differently and nobody noticed until working software made the difference visible. "Show me active customers" is agreed by six people in a room, and it turns out finance, sales and support have three different definitions of active, all of them defensible. That is discovered in week nine, and it is not a change request. It is a decision that was never made, arriving late and expensive.
A dependency on someone with no deadline. Your vendor has a contract and a date. The team that owns the source database has neither. When those two meet, the one without a deadline wins every time, and the delay is invisible in status reports because nobody's task is late. Everyone is blocked, which is not the same as being behind, right up until it is.
An estimate given before anyone looked at the data. This one is the vendor's fault and it is worth naming plainly, because buyers reward it. A firm that quotes a fixed number and a firm date after a one-hour call is guessing, and the guess is priced to win the work. The honest answer at that stage is a range wide enough to be useless for planning, which is why a short paid discovery exists: it converts the wide range into a narrow one before anybody commits. Buyers who insist on a firm number before discovery get one. It is just not true.
How much schedule risk each factor carries — our default weighting
Our ranking of what puts a date at risk, drawn from the projects we are asked to rescue. Judgment, not measurement — the ordering is the useful part, and the last row is the one everybody worries about first.
An estimate is a distribution. Ask for both numbers.
A single date is a compressed summary of a range, and the compression is where the honesty goes. Ask any team for two numbers instead: the date they would hit half the time, and the date they would hit nine times out of ten. If the answer is "twelve weeks" and "twenty weeks," you now know something real, and you can decide which one goes in front of your board. If the two numbers are the same, the team has not thought about it, and you should treat the single number as marketing.
The second question is better and almost nobody asks it: what did the last three projects like this one actually take? Human beings are reliably optimistic when they estimate from the inside of a plan, and reliably accurate when they look at how long similar work took before. If a vendor cannot answer that question about their own history, the estimate is an opinion. If they can, and the answer is uncomfortable, you have found a firm worth hiring.
The signals that show a slip six weeks early
Percent-complete does not predict anything, because it is a self-report of a self-estimate. These do, and every one of them is countable by a non-engineer in about ten minutes a week.
- Open decisions, and their age — a list with dates. Three open questions older than two weeks is the single most reliable early warning there is.
- Days since the vendor first read your real data — not a sample, not a spreadsheet extract. The production shape, in their environment.
- Whether the risky integration has been attempted at all — one call, one response, in week one. Teams postpone it because it is unpleasant, which is exactly why it belongs first.
- Running software demonstrated this week — clicked, not screenshotted, not described. A demo of something small is worth more than a status deck about something large.
- Acceptance criteria written and countersigned — if you cannot name the test that ends the argument, the argument has no end.
- Requests to move a scope item later — the first one is fine. The third is a schedule telling you what it thinks.
One rule about the fourth item: insist that every demonstration runs in an environment you can also reach, from a build that came out of the repository, on data that resembles yours. A demonstration on a developer's laptop with a curated file is a demonstration that the developer's laptop works.
What the buyer controls, and it is more than you think
Vendors take the blame for dates, which is mostly fair and slightly misleading. In the projects we are called into after a slip, the fastest available acceleration is usually on the customer's side of the line, and it is free.
Name one decider and give them a service level. One person who can settle a definitional question in 48 hours, with the authority to be wrong. Committees do not decide; they schedule. A weekly meeting turns a five-minute question into a seven-day round trip, and six of those is a month and a half.
Start access before the contract is signed. The security review, the VPN account, the read replica, the sandbox credentials in the third-party system. None of that requires a signed statement of work to begin, and all of it is on the critical path from day one. This one change routinely saves three weeks and costs nothing.
Write acceptance criteria you could hand to a stranger. Not "the report is accurate." Instead: these fifty records, this expected output, this tolerance, run by this person. It feels bureaucratic when the relationship is new and it is the cheapest insurance available.
Sequence for a useful thing early. Ask for the smallest version that a real user could actually use in production, in the first third of the schedule. It is not about agile ceremony. It is that shipping something forces every hidden dependency into the open while there is still time and money to deal with it. A project whose first production release is scheduled for the final week has no plan; it has a hope.
A weekly list of open decisions, with dates, sent to the sponsor
One page. Every unanswered question, who owns it, how long it has been open, and what is blocked behind it. No status percentages, no traffic lights. It takes an engineer ten minutes to maintain, it is impossible to fake, and it converts the vague feeling that something is wrong into a specific list of names and dates. In our experience it moves more schedule than any tooling change, and it works whether or not the vendor cooperates, because you can maintain it yourself from the questions landing in your inbox.
Send us the plan and we will tell you where it breaks.
Email the statement of work, the current schedule and the list of things you are waiting on to contact@precisionfederal.com. You get back a short written note naming the three items most likely to move your date and what we would do about each. One business day. No charge, no meeting, no deck.
contact@precisionfederal.comWhat to do when it has already slipped
Re-baseline once, in public, with a range. A project that moves its date four times by two weeks each has destroyed more trust than one that moves it once by two months. The serial small slip is a symptom of a team estimating the remaining work from inside the same fog that produced the original number. Stop, re-plan the remainder from what is actually built, and publish two dates rather than one.
Cut scope, not quality. Under pressure, the tempting savings are testing, documentation and the handoff material, because none of them are visible in a demo. Every one of those comes back within two quarters at a multiple, and the handoff material comes back at the worst possible moment. Cut features. Ship six things that work rather than eleven that mostly do.
Do not add people to a late project. Fred Brooks wrote that down in 1975 and it has held up for fifty years, for the reason he gave: new people consume the time of the people who already know the system, and communication paths grow faster than headcount does. There are narrow exceptions, all of which involve genuinely separable work with a clean interface. Adding three engineers in month five to "help" is not one of them.
Change what gets reported. Replace percent-complete with a list of what a user can do today that they could not do last week. If the list is empty three weeks running, the problem is not the schedule.
Fixed price does not remove the risk. It prices it.
Buyers reach for fixed price because it appears to transfer schedule risk to the vendor, and to a degree it does. What it also does is put the vendor's margin in direct conflict with your change requests, which is fine when scope is genuinely settled and corrosive when it is not. A fixed-price contract on unsettled scope produces a firm with a commercial incentive to interpret every ambiguity narrowly, and the relationship becomes an argument about what the words meant.
Time and materials is more honest about uncertainty and requires you to steer. If you are not going to read a weekly burn report and make decisions from it, you should not sign one. The structure we prefer for work with real unknowns is a small fixed-price discovery that produces the scope, followed by fixed-price increments against that scope, each small enough that a bad estimate costs weeks rather than quarters. It is not a clever contracting trick. It just puts the pricing decision after the learning instead of before it.
The mistakes we are called in to fix
- A firm date quoted before anyone had seen the production data, then defended for four months
- The hardest integration scheduled last, because it was the least pleasant to start
- No named decider, so every definitional question waited for a standing meeting
- Acceptance criteria written as adjectives — accurate, fast, intuitive — and therefore untestable
- Status by percent-complete, which cannot go down and therefore cannot warn
- Three engineers added in month five, slowing the two who knew the system
- Testing and documentation cut to hold a date, and re-bought at a premium two quarters later
- A first production release scheduled for the final week, so every hidden dependency surfaced at once
A two-week reset for a project that is already late
Recovery sequence
Step three is the one that gets skipped and the one that pays. Every project carries one assumption that, if wrong, invalidates the plan — a rate limit, an authentication model, a field that turns out to be free text, a data volume nobody measured. Two weeks spent proving or breaking that assumption is the highest-return time available on a late project, and it stays true right up until delivery.
Before you sign a schedule
- You have two dates, not one, and you know which one is the commitment
- The vendor has seen real data in their own environment before quoting
- Access requests are open with your own IT before the contract is countersigned
- One person is named as decider with a written response time
- Acceptance criteria exist as tests a stranger could run
- The riskiest integration is scheduled in the first two weeks
- Something usable reaches production in the first third of the calendar
- Weekly reporting is a list of decisions and demonstrated capability, not a percentage
- Contingency is a line item somebody owns, not an unstated hope
Bottom line
Schedule slip is not mostly a story about engineers working slowly. It is a story about a plan that counted the construction and left out the access, the decisions, the integration and the acceptance, and then measured progress with a number that cannot go down. The controllable parts are unglamorous and available immediately: settle the definitions, open the access early, attempt the frightening thing first, and insist on seeing working software every week. Do those four and the date still moves sometimes, because real work is uncertain. It moves once, by an amount you can plan around, and you find out early enough to decide what to do.
Frequently asked questions
For a well-understood build against systems you control, fifteen to twenty percent is defensible. Add a third-party integration, an unfamiliar data source, or a regulated approval and thirty to fifty percent is closer to honest. The important part is not the percentage but that it is a named line somebody owns, rather than padding hidden inside individual estimates where it quietly gets spent.
Neither prevents an overrun; they decide who absorbs it and what behavior it encourages. Fixed price works when scope is genuinely settled and produces adversarial change-order arguments when it is not. Time and materials is honest about uncertainty but only works if someone on your side reads the weekly burn and makes decisions. A short fixed-price discovery followed by fixed-price increments against the resulting scope gets most of the benefit of both.
Usually not. New people consume the time of the people who already understand the system, and coordination cost grows faster than headcount. The exception is genuinely separable work with a clean interface, staffed by people who need no ramp-up. If the work is entangled with what is already late, adding people makes it later.
A list of open decisions with ages on it. Three questions older than two weeks, with work stacked behind them, predicts a slip more reliably than any burndown chart. The runner-up is the number of days since the team first ran against your real production data in their own environment; if that number is still climbing in week four, the estimate is describing a system nobody has met.
Stop asking for percentages and ask for a demonstration in an environment you can reach, from a build produced by the repository, against data that looks like yours. Then ask for the list of open decisions and external dependencies with ages. Those two requests take a day to answer and will tell you whether the remaining ten percent is a week or a quarter.