8. Schedule from Real Dependencies and Honest Critical Path

The status slide shows a launch date that has not moved in three months.

The dependency file under it moved every week.

By the end of Tuesday the two had drifted far enough apart that only one of them could still be true. The projector was showing the other one.

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.

Three rules that keep the path honest when date pressure starts:

• 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

The distortions appear in the same order on every program. Naming them is faster than re-diagnosing from scratch:

• 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. That revision was discovered and communicated four months before launch, not two weeks before. 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 — four months of decisions that had been made 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.

When the dependency chain is live and the weekly cadence publishes a delta note, the PM reads the path delta before the review instead of re-deriving it in the meeting. That is the whole reason to recompute every cycle: the schedule answers the status question before anyone has to ask it.

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. What cannot vary is 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.

Field test: find the next major milestone on your program. Can you name the three real physical or procurement dependencies that drive that date, and point to their current values in a controlled record? If the date is a commitment rather than a dependency calculation, the schedule is a target, not a plan.

Trace your own launch date back through its predecessors. If the chain runs into a requirement value nobody grounded in physical evidence, the dependencies are honest and the date is still fiction — the fault is one layer down, in the numbers the schedule was told to trust.