Critical chain: dependencies, resources and buffers

Critical chain: dependencies, resources and buffers

Project delay can come from resource contention even when a task-dependency diagram looks reasonable. Identify the shared resources as well as the order in which work must occur, then build a feasible plan. Make uncertainty protection visible at the project and feeding connections rather than hiding it independently in every task. Limit harmful switching among too many active jobs and review buffer consumption to focus support. Do not mechanically halve all estimates or label an ordinary critical path a critical chain. The small network introduces the mechanism; actual project commitments require credible estimates, resource calendars and the relevant planning expertise.

Follow the method

1. Ready project
2. Task A
3. Task B
4. Integrate
5. Project protection
6. Deliver
7. Independent feeder
8. Feeding protection

Separate resource order from the integration dependencies

Fictional engineering project: tasks A and B can both start after the project is ready, but each needs the same specialist. Integration requires outputs from A, B and an independent feeder F performed by another resource. Planner Hana must turn the logical network into a resource-feasible proposal. Durations and buffer sizes are not supplied.

Follow the method

1. Ready → A and B
2. A → B in proposal
3. F → Integration
4. Feeding / project protection
5. Completion date / chain length

Two ready tasks still need one specialist

Distinguish task dependencies from shared-resource ordering, retain an independent feeder and its protection, and identify why an un-timed network cannot establish a promised completion date.

Fictional engineering project: tasks A and B can both start after the project is ready, but each needs the same specialist. Integration requires outputs from A, B and an independent feeder F performed by another resource. Planner Hana must turn the logical network into a resource-feasible proposal. Durations and buffer sizes are not supplied.

Role: Project planner with task owners and the shared specialist.

Normal condition

The plan respects prerequisites, finite resource availability and the accepted project outcome.

The gap

A schedule starts A and B simultaneously and omits the feeder’s joining risk.

• A-before-B is the illustrative resource ordering, not a claim that B technically depends on A.
• No durations are supplied; the example cannot calculate a critical chain length or justified buffer size.

1. Draw the logical dependencies

   Hana connects Ready to A, B and F, then connects all three required outputs to Integration. She records acceptance conditions for each handoff.

   Why: A missing feeder can make an apparently complete main path unusable. Logical readiness and resource availability are separate questions.

   Evidence: Integration has three prerequisite outputs, including F.

2. Resolve the shared specialist conflict

   For the illustrative proposal, sequence A before B on the specialist’s lane. Label that link as resource ordering, not a newly discovered technical dependency.

   Why: One specialist cannot perform incompatible tasks simultaneously. Distinguishing link types preserves options if priorities or resource availability change.

   Evidence: A and B no longer overlap on the same resource; F can proceed independently if its own conditions hold.

3. Locate protection without inventing its size

   Show feeding protection at F’s connection into Integration and project protection before committed accepted delivery. Leave durations and sizing decisions unspecified.

   Why: Protective buffers are explicit management provisions. Their placement and sizing need a coherent project model and uncertainty evidence, not decorative boxes or a universal percentage.

   Evidence: Feeding and project protection have different locations and purposes; no numeric sizes are claimed.

4. Obtain the data required for a real schedule

   Gather task-duration estimates with their basis, calendars, resource commitments, readiness constraints and risk assumptions. Then analyze a resource-feasible network and justified protection policy.

   Why: Without durations and resource conditions, the drawing teaches interaction but cannot identify the actual limiting chain or promise a completion date.

   Evidence: Required scheduling inputs and responsible owners are listed.

5. Manage execution and learn from protection use

   During the eventual approved plan, keep readiness, remaining work and agreed priorities visible. Review repeated interruptions or feeder failures with their owners.

   Why: Starting many tasks to show activity can increase harmful switching while delaying the accepted project outcome.

   Evidence: Execution review addresses the project’s commitments rather than each task’s appearance of busyness.

The feeder now needs the same specialist

A scope change makes F depend on the same specialist as A and B.

Rebuild the resource-feasible sequence and reassess the network/protection assumptions; do not leave F running independently on the old chart.

Changing a resource requirement can change the limiting schedule even when the logical output dependencies remain unchanged.

Revised resource assignment and sequence are explicit; timing remains uncalculated until data exist.

Run a practice session

Materials

• Task cards, two resource lanes and two distinct protection symbols
• Blank network; no fabricated time grid

1. Separate two kinds of readiness · 4 minutes

   Can both tasks be ready while only one can run?

2. Build the A/B/F network · 8 minutes

   Which link is caused only by the shared specialist?

3. Solve the C/D/E case · 8 minutes

   What makes the feeder independent?

4. Challenge a promised date · 5 minutes

   Which missing inputs make that promise unsupported?

Debrief

• Ask learners to redraw the feeder after the resource-change exception.
• Do not accept a numeric buffer inserted without a basis.

Use different line styles for prerequisites and resource order, then audit every integration input.

Transfer into the work

Owner: Project owner with planner and resource owners

Record: Resource-feasible network, estimate basis and explicit protection policy

Review: At planning approval and meaningful scope/resource changes, then during execution

Evidence: Feasible assignments, ready handoffs and accepted project delivery against the approved basis

Replan through the project owner; address recurring readiness or resource conflicts rather than hiding task padding.