Schedule and cost are coupled — treating them as independent is the failure mode

Schedule and cost are the same conversation. Treat them as separate and the conversation lies.

Project schedule and project cost are usually managed by different people, tracked in different artifacts, and reported on different cadences. Schedule lives in the PM's Gantt or sprint board; cost lives in the finance team's spreadsheet; the two intersect at the steering committee meeting once a month, when someone notices they have drifted apart. By the time anyone notices, the drift is usually two months old.

The reason this matters is that schedule and cost are not independent variables. They are two sides of the same value-vs-burn coin: schedule tells you how much work has been done; cost tells you how much was paid for it. The ratio of the two is the project's actual performance. A project that is on schedule but over budget is delivering less per dollar than planned. A project that is under budget but behind schedule is paying less but also producing less. Reading either number alone tells you a story; reading them together tells you the truth.

This piece is the long-form anchor for the Schedule & Cost pillar. It walks estimation honestly, treats Earned Value Management as the underrated discipline most teams skip, and ends with the specific failure modes that produce most schedule-cost surprises.

§1 — Estimation, honestly

Estimation is the hardest part of schedule and cost work, and it is hard for a structural reason: the work is being estimated by people who have never done exactly this work before. Every project is novel along at least one dimension. The estimate is, definitionally, a guess.

The right way to estimate is to acknowledge the guess and bound it. The wrong way is to produce a single number and treat it as a commitment. Two approaches account for most credible estimation in the wild.

Three-point estimates. For each work item, the team produces three numbers: optimistic (best case), most likely (expected), and pessimistic (worst case). The expected duration is a weighted average — (optimistic + 4 × most_likely + pessimistic) / 6 is the PERT formula and it works well enough. The point of three-point estimation is not the formula; it is forcing the conversation about what could make this go badly at estimation time, not at execution time.

Reference-class estimation. Instead of estimating from first principles, look up how long the same kind of work has taken on past projects. The team produces a base rate (median of similar past work) and an adjustment factor (how this project differs from the reference class). Reference-class estimation is more accurate than first-principles estimation almost always — see Kahneman's Thinking Fast and Slow §23 for the underlying research.

The organizations that estimate well do both: three-point estimates calibrated against reference-class data. The organizations that estimate badly do neither — they ask senior engineers for a number, write the number down, and treat it as a commitment.

§2 — Earned Value Management, the underrated discipline

EVM has a reputation problem. It is taught as a heavyweight defense-industry discipline, full of acronyms and formulas. Most software PMs skip it. This is a mistake, because EVM at its lightweight core is the only mechanism that catches schedule-cost decoupling early.

The core of EVM is three numbers updated weekly:

• Planned Value (PV) — the budgeted cost of the work that should have been done by now, according to the schedule.
• Earned Value (EV) — the budgeted cost of the work that has been done by now.
• Actual Cost (AC) — the dollars actually spent so far.

From these three, two ratios fall out:

• Schedule Performance Index (SPI) = EV / PV. If 1.0, on schedule. If <1.0, behind.
• Cost Performance Index (CPI) = EV / AC. If 1.0, on budget. If <1.0, over.

The magic is in reading both at once. SPI = 0.9 and CPI = 0.9 means the project is behind on schedule and over on cost — the work is genuinely going badly. SPI = 1.0 and CPI = 0.7 means the project is on schedule but spending 40% more than planned to get there — usually because contingency is being silently consumed. SPI = 0.7 and CPI = 1.0 means the project is behind schedule but under budget — usually because the team is short-staffed and the missing work is just not happening.

§3 — When EVM is overkill, when it is exactly right

EVM is overkill for some projects and exactly right for others. The cutoff is not project size; it is whether the cost-of-being-late or cost-of-overrun is high enough to justify the tracking overhead.

EVM is overkill when:

• The project is short (under 3 months) and the variance ceiling is small. The tracking overhead exceeds the value of the early signal.
• The project is staffed by a small fixed team with no external contractors. AC tracks closely with PV by construction; SPI carries most of the signal alone.
• The cost of being late is low. The project is internal-tooling work and a month-late delivery is a shrug, not a crisis.

EVM is exactly right when:

• The project has external commitments (contractor work, regulatory dates, customer-facing launches). The variance is expensive when it materializes.
• The project staff varies week to week. AC and EV decouple in interesting ways and reading them together is the only honest signal.
• The budget is large enough that a 10% overrun is a five- or six-figure problem.

For everything in between, lightweight EVM — SPI and CPI updated monthly, no full EAC computation — gets you 80% of the signal at 20% of the cost. The PMs who skip EVM entirely are not skipping for the right reason; they are skipping because they have been told it is heavyweight, and never tried the lightweight version.

§4 — Procurement is part of the schedule

Procurement gets treated as a finance concern in most projects. It is not a finance concern; it is a schedule concern. The vendor's lead time, the legal review window, the procurement-team queue depth — these are dependencies on the project's critical path, the same as any other dependency, and they need to be represented as such in the plan.

Three procurement patterns account for most procurement-driven slip:

• The legal-review surprise. The team budgets two weeks for vendor legal review. The actual lead time is six. The team did not check before committing the project's date.
• The procurement queue. The procurement team handles requests in arrival order and is currently four weeks deep. The project's vendor request goes in the queue with everyone else's. Two weeks of slip.
• The dependency-on-a-dependency. The project depends on Vendor A. Vendor A depends on Vendor B's API. Vendor B has deprecated the API. The PM finds out from the vendor in week 12.

The fix is the same in every case: include procurement timelines in the plan with the same rigor as engineering work. Treat legal-review-of-vendor-X as a 30-day item on the schedule, not as a side-task. Build in the queue depth, not just the work depth.

§5 — The four most common failure modes

The schedule-cost failures we see across customer engagements cluster.

The optimistic estimate without contingency. The team estimates 12 weeks. The schedule shows 12 weeks. There is no contingency. The first deviation eats into the delivery date directly, and the project is behind from week one. Fix: every schedule has named contingency, with rules about when it can be drawn down and who approves the draw-down.

The silent contingency consumption. There is contingency in the schedule, but it is not labeled. As deviations accumulate, the team quietly absorbs them by working overtime or de-scoping silently. From the steering committee's perspective, the project is on schedule. From the team's perspective, contingency is gone by week six. Fix: contingency is a line item, drawn down explicitly through the change-control process.

The cost overrun without schedule signal. The team is on schedule but burning faster than planned, usually because contractors are being added to keep the schedule. The schedule looks fine until the moment the budget runs out, at which point the schedule collapses. Fix: CPI tracking, monthly minimum.

The procurement assumption. The plan assumes the vendor will deliver in N weeks, where N is the engineer's estimate, not the vendor's commitment. Fix: every external dependency has a written commitment from the external party, not an internal estimate.

§6 — How to use this pillar

The rest of the Schedule & Cost pillar walks estimation methods in depth, the lightweight EVM playbook, the procurement-as-schedule treatment, and the contingency discipline that distinguishes projects that ship on commit from projects that ship eventually. If you have never run EVM, start with the lightweight piece. If your estimates regularly miss, start with the reference-class piece.

The meta-rule: schedule and cost are the same conversation. Track them together, read them together, report them together. The discipline is boring and decisive.