You usually find out on a Thursday, and almost never from a status report. A ticket that was done last week is open again. An engineer answers a question with a caveat nobody mentioned at kickoff. You do the arithmetic on the way to a different meeting and the date you promised your client stops being plausible. From that moment two clocks are running — the one in your subcontract and the one in the agreement with your name on it — and only one of them your client has ever read.
Start by being honest about what you sold. The date you gave your client was almost certainly a single number produced by someone estimating their own work, with no allowance attached. Federal scheduling practice treats that as a category error. In its guide to project schedules, the US Government Accountability Office describes the allowance a schedule is supposed to carry: "The contingency represents a gap in time between the finish date of the last activity (the planned date) and the finish milestone (the committed date)." Two different dates, deliberately. The guide explains why the gap has to be real rather than decorative: "because schedule distributions tend to be right skewed (that is, the program has a greater tendency to finish late than early), the mean of the distribution tends to be larger than the 50 percent confidence level" — and notes that "For some programs, the 80th percentile is considered a conservative promise date" (US Government Accountability Office, Schedule Assessment Guide: Best Practices for Project Schedules, GAO-16-89G, December 2015, Best Practice 8, p. 117).
Read that against how an agency actually sells. The planned date and the committed date are the same date, because the contingency got spent in the pitch. When the work is subcontracted the buffer is usually given away twice: you compress the date to win, then your partner quotes you that same number with no reserve of their own, because you asked them for a date rather than for a distribution. The guide is clear about where the reserve belongs — it "is held by the program manager but can be allocated to contractors, subcontractors, partners, and others as necessary for their scope of work." Held by you, allocated by you, and visible in your plan even when it is not visible in theirs.
The size of the tail is the part principals underestimate, and it has been measured. Bent Flyvbjerg and Alexander Budzier analysed a sample of 1,471 IT projects and reported that "the average cost overrun was 27% - but that figure masks a far more alarming 'fat tail' risk. Fully one in six of the projects in the sample was a Black Swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%" (Bent Flyvbjerg and Alexander Budzier, Why Your IT Project Might Be Riskier Than You Think, arXiv:1304.0265, published in Harvard Business Review, Vol. 89 (2011), No. 9, pp. 23–25). The useful reading is not that projects run late on average. It is that the average is the wrong planning quantity: most engagements land near the estimate and a minority land somewhere overtime cannot reach. You are not managing a 27 percent problem. You are managing a one-in-six problem, and you only learn which kind you have from inside it.
Whose fault it is turns out not to be a defence, and settling that early shapes every conversation that follows. Even federal contract language — written in an environment far more sympathetic to a prime contractor than your client's master services agreement is to you — carves your situation out by name. The Excusable Delays clause opens: "Except for defaults of subcontractors at any tier, the Contractor shall not be in default because of any failure to perform this contract under its terms if the failure arises from causes beyond the control and without the fault or negligence of the Contractor." A subcontractor's failure is excused only where "the cause of the failure was beyond the control of both the Contractor and subcontractor, and without the fault or negligence of either" — and not even then if "The subcontracted supplies or services were obtainable from other sources" (Federal Acquisition Regulation, 52.249-14 Excusable Delays, Apr 1984; FAC 2026-01). Capacity obtainable from other sources is the definition of what an agency subcontracts. The clause is describing you.
Now the part you can change: finding out earlier. Lateness is almost never a single event; it is a small slip absorbed quietly, then another. The scheduling vocabulary for this is float: "total float is the time an activity can slip before its delay affects the program end date," and where a network is free of date constraints, "any delay in the critical activity causes the same day-for-day delay in the program forecast finish date" (GAO-16-89G, Best Practice 6, p. 75). The trap is watching the wrong items. The guide warns that "an important activity is not necessarily 'critical'" — "some mundane activities—training, for example—may be on the critical path and not particularly risky but can delay the program finish date if they take longer to accomplish" — and that near-critical paths "need only a small extension of time to become critical" (p. 76).
Translated into agency practice, that is an instruction about what to ask for weekly. Not a percentage complete, not a colour, not a paragraph of prose. Ask which items are now on the longest path to the date, what the float is on the ones just behind them, and what moved onto that path since last week. A partner who can answer is managing a schedule; a partner who cannot is reporting activity. What to ask for in a weekly update is the format, and it works identically whether your own engineers or a partner's filled it in.
Three signals reliably precede an admitted slip. Rework: closed items reopening, which means the definition of done was softer than the plan assumed. Repetition: the same blocker in two consecutive updates with the same wording — usually a dependency on your side or your client's, unresolved because raising it twice felt rude. And the estimate that stops moving: remaining effort reported as the same number three weeks running is not stability, it is an estimate nobody is recalculating.
Do not respond by adding people. It is the reflex, and the guide records it as the normal institutional behaviour rather than the correct one: "Typically, schedule variances are followed by cost variances and management tends to respond to schedule delays by adding more resources or authorizing overtime." On a subcontracted build it is worse than usual: the new engineer has to be onboarded by the engineer who is already behind, in a codebase your own staff cannot explain, and that cost lands directly on the path you are trying to protect. Where extra capacity genuinely helps, it helps on work that is parallel and separable — a migration, a test suite, a second surface — not on the thing that is late.
There are four honest moves, and they are worth ranking before you are emotional about them. Cut scope: cheapest, fastest, the only one that preserves the date — provided you cut a whole capability rather than the finishing on all of them. Move the date: expensive in trust, cheap in money, right when the remaining scope is genuinely load-bearing. Redefine done: ship the narrower thing on the date and schedule the rest, which is cutting scope except that you have said when the rest arrives. Absorb it: hold the date, hold the scope, and pay for the overrun out of margin. That last one is real and sometimes correct — on a first engagement with an account you intend to keep for five years it can be the cheapest marketing you will ever buy. It stops being an option the second time.
The call with your client happens within a day, and it is yours to make. Not a Friday email. The structure that survives contact: what has changed, the new date, what you are doing about it, what you need from them — in that order, with the new date stated as one date rather than a range. A range tells your client you still do not know, which is what they are actually worried about. Then make the new date defensible in the way the first was not: say what it assumes, name the item that would move it again, and give it a reserve you keep. Better to name a date you beat than to renegotiate twice — renegotiating twice is what turns a schedule problem into a competence problem.
Do not put your delivery partner on that call to explain it. The instinct is that whoever knows the detail should speak, and it is the most expensive shortcut available to you — who your client trusts when you subcontract is the mechanism in full, and a missed date is when it runs fastest. Bring a specific, checkable technical answer instead, sourced from your partner an hour earlier and delivered in your own words.
Then settle the money, on a different day. Your subcontract either has a remedy for this or it does not, and the discovery usually arrives too late to be useful. Fee at risk against a milestone, a replacement guarantee with a period attached, a change-control process naming who approves an overrun before it is incurred — what belongs in a white-label subcontract covers the clauses that make a late build a negotiation rather than a surprise. What not to do is let a schedule dispute become a payment dispute while that team is still the only team who can finish the work.
The rebaseline is where the lesson either lands or evaporates. Three changes before the next engagement. Hold a reserve between the date you plan to finish and the date you commit to, and do not tell the delivery team where it is. Require a schedule you can interrogate — the longest path, the float behind it, what moved — rather than a status narrative. And write the slip down: the first signal, how many days passed before anyone named it, and which of the four moves you took. Where the capability is well understood and the date is genuinely fixed, a scoped sprint is the safer shape because it ends on a boundary you chose; the long multi-year builds — the kind of consolidation work behind the 150-branch platform we delivered for Concordia Colleges — stay predictable only when they are run as a sequence of those boundaries rather than one long promise.
Prepare one more thing in advance: the handover position. If the answer to a serious slip is that you change partners, you can only do that if the work already lives in your repositories, tracker and pipeline — the handover: what you must receive is the same checklist read from the other side. An arrangement you could end makes a hard conversation a negotiation. One you could not end is a conversation where you have already conceded, and both parties know it.
The test: could you tell your client the exact truth about why the date moved, in one paragraph, without it costing you the account? If yes, the slip is a slip. If the honest sentence is one you cannot say out loud — that you do not know why, or that you found out three weeks after your partner did — the schedule was never the problem you had. That is the question worth asking of any white label software development partner before you sign, and the answer is not in their case studies. It is in what they send you on a normal Tuesday when nothing is wrong.
Find this useful? Tell Google to show you more of it.