8. Schedule from Real Dependencies and Honest Critical Path

Tuesday, 5:50 p.m., long shadows in the program office, dependency chart finally honest.

The launch date on the slide has not moved in three months.

The dependency chain under it has moved every week.

This is date reporting without dependency control: leadership still sees a fixed milestone and "progress" language while nobody owns a live predecessor graph — the tasks, durations, buffers, and handoffs that would force the date to move when the work underneath moves.

A schedule is a model, not a promise

The launch date is an output of the dependency model.

The model is dependencies, durations, and uncertainty.

When teams treat the date as fixed input and dependencies as optional narrative, recovery arrives too late.

Dependency-first schedule logic starts with:

  1. required outcomes,
  2. prerequisite tasks,
  3. ownership of each task,
  4. uncertainty ranges,
  5. integration constraints between streams — where work in parallel has to meet (interface freezes, shared builds or fixtures, hardware–software bring-up order, qualification artifacts that block the next stream).

Then the planning lead computes the date from that model instead of declaring it in advance.

Honest critical path

Critical path is not "the work we care about most."

It is the chain that controls completion date.

Rules for honest path management:

  • recalculate path when task state changes,
  • include external dependencies (supplier lead time — procurement and qualification clock from order or release to usable parts — plus compliance, tooling),
  • include integration and validation tasks (not only build tasks),
  • show float explicitly.

If your plan has no visible float and no uncertainty ranges, the schedule has no tested recovery path.

Failure modes that fake schedule confidence

Common schedule distortions:

  • compressing non-critical tasks and calling it recovery,
  • hiding blocked dependencies in "in progress" buckets,
  • assuming parallelism where shared people/equipment make it serial,
  • reporting roll-up percent complete while gate or sign-off prerequisites stay blocked — percent complete tracks effort and checklist breadth; decision readiness tracks whether the next honest gate, signature, or integration step is unblocked. Optimizing for the first lets teams paint progress green while prerequisites for the real decision are still missing.

These behaviors protect optics and destroy forecast quality.

At an energy storage program, the announced launch date had not moved in three months on the program slide. Underneath, three thermal-related long-leads had quietly slipped: the cold-plate extrusion (11 working days, triggered by the thermal limit revision that changed the geometry requirement), the thermal interface material qualification (8 days, triggered by the contact-resistance finding), and a chamber booking for the revised configuration (6 days, because the test queue had moved). That geometry revision forced a new extrusion cross-section the original schedule had no entry for. None of the slips were visible on the schedule because the schedule had been built date-to-date, not dependency-to-dependency.

When the team recomputed the chain — what depends on what, with honest durations and buffer for uncertainty — the new date was 19 working days beyond the announced date. The recovery conversation that followed was real: cut one product variant from the launch scope, change the supplier extrusion sequence to overlap with qualification, fund a parallel chamber booking. The conversation was hard. It was also the first honest program conversation in three months. - Old process: schedule defended date-to-date with narrative compression.

  • Artifact changed: the dependency chain rebuilt from real durations with three named recovery levers (scope, sequence, resources).
  • Measured improvement: 19-day date revision discovered and communicated four months before launch, rather than two weeks before.
  • Cost of the gap: four months of decision-making downstream of a date everyone knew was wrong.

Weekly cadence for schedule truth

A useful weekly cycle:

  1. Refresh task state from owners.
  2. Recompute dependency chain and current critical path.
  3. Identify path deltas since last cycle.
  4. Publish schedule delta (path and date impact) in the one-page status.
  5. Trigger escalation where recovery needs scope/resource decision.

If the team does not recompute dependencies each cycle, the status packet is not decision-grade.

A PM who trusts the schedule stops chasing daily status. That shift is not a sign of disengagement — it is the signal that the artifacts are doing their job. When the dependency chain is live and the weekly cadence publishes a delta note, the PM has something reliable to read before the review. The engineering lead who has earned that trust has bought themselves protected time to solve the technical problem instead of presenting it repeatedly.

Acceptable homes for the dependency-based schedule are those where the program can rely on the same facts: one place everyone can open without hunting, a stable reference link from your program hub, predecessor links or an equivalent explicit dependency map that is maintained when work changes, and a visible history of plan churn (what moved, when, and why) so weekly deltas are not argued from memory. That can be a Gantt file, a table with a maintained dependency column, or a version-controlled outline — scale and ceremony should match program size. The OS does not care which format holds the model; it cares that the date is derived from the dependency chain and uncertainty fields — not set first and defended by narrative compression.

What real recovery requires

Recovery has three levers:

  • change scope,
  • change sequence,
  • change resources.

"Work harder" does not change dependency structure, so it cannot be a fourth lever.

For every recovery claim, require:

  • which lever is being used,
  • which dependency it changes,
  • what risk it adds,
  • who approved the trade.

Without these four fields, recovery is rhetoric.

Link to gates and one-page truth

Schedule integrity depends on records you already built:

  • decision logs (what changed),
  • risk register (what can slip next),
  • one-page truth (what leadership sees),
  • ownership map (who closes blockers).

If these are weak, schedule updates drift into negotiation instead of model updates.

If your plan has no visible float and no recovery lever named in writing, you do not have a schedule. You have a date with a story around it.