Dependency Graphs, Critical Path, Coupling, and Integration Sequence

Mission

By the end of this chapter, you can build and challenge a dependency graph, identify the current critical path and slack, and choose a staged integration sequence.

• Measurable outcome: Build and challenge a dependency graph, identify the current critical path and usable slack, classify coupling, and choose an evidence-driven integration sequence.
• Prerequisites: Chapters 13–14; basic estimation concepts.
• Work product: A dependency graph and integration plan for Meridian Pay.
• Time: 80–100 minutes.

Before you read: Predict → Commit → Connect

Predict: If the longest engineering task finishes first, can the program still be late? Write the reason.

Commit: Name one dependency that is technical, one that is a decision, and one that is external to your organization.

Connect: Recall a milestone that slipped “unexpectedly.” Which predecessor, assumption, or shared resource was invisible?

Model the logic before the dates

A dependency is a condition that constrains when or how another piece of work can proceed. A list of dates does not show dependency logic. A graph does.

Represent meaningful activities or evidence-producing milestones as nodes and prerequisite relationships as directed arrows. Use enough detail to reveal decisions, external lead times, shared environments, and integration evidence. Avoid turning every small task into a node; the graph is a reasoning tool, not a replacement for team plans.

Classify dependencies because each class needs a different response:

• Hard technical: downstream work cannot function without the predecessor.
• Information or decision: work waits for a requirement, approval, or trade-off.
• Resource: activities compete for a person, environment, supplier, or test asset.
• External: a regulator, vendor, customer, or physical shipment constrains progress.
• Soft or preferential: an order is convenient but can be changed at a cost.

Challenge every arrow: “What specifically becomes impossible if this predecessor is incomplete?” Some claimed dependencies are habits. Removing or weakening them can create parallelism. Other arrows are missing because teams have not discussed semantics, approvals, or operating transitions.

The graph exposes a fact that a status table can conceal: approval and semantic decisions can sit on the same path as code. Estimated durations should be ranges or explicit planning values, not claims of certainty.

Critical path and slack are dynamic

The critical path is the longest dependency-constrained path through the modeled work; under the model's assumptions, delay on that path delays the endpoint unless the plan changes. Slack or float is how much an activity can move before affecting a constrained successor or endpoint.

Critical-path analysis is conditional. Duration uncertainty, resource contention, rework, calendars, and newly discovered dependencies can change the path. A TPM should say “current modeled critical path,” name the assumptions, and recalculate after material changes. A near-critical path with high uncertainty may deserve more attention than a deterministic-looking critical path.

Do not respond to every critical task by adding people. Some work cannot be divided efficiently, and added coordination can slow it. Options include resolving the predecessor earlier, reducing scope, changing sequence, creating a simulator, decoupling an interface, reserving scarce resources, or choosing a different milestone.

Coupling determines coordination cost

Two workstreams are tightly coupled when one frequently needs the other's internal state, changes, timing, or approval to make progress. Coupling may be:

• technical, through synchronous behavior or shared data;
• temporal, because releases must happen together;
• organizational, because authority is split across groups;
• operational, because failures or ownership cross a seam;
• knowledge-based, because critical context resides with a few people.

Reducing coupling does not mean eliminating collaboration. Stable contracts, versioning, simulators, representative test data, clear decision rights, and independent release mechanisms let teams coordinate intentionally rather than continuously.

This is an integration sequence, not merely a release sequence. It orders learning from cheap, reversible tests to more realistic and consequential exposure. Integrate the riskiest assumptions early enough to change course. Do not wait for every component to be “complete” before discovering that the whole cannot reconcile.

Recurring case: Meridian Pay

Meridian's first plan showed the regional service completing in September and traffic migrating in October. The dependency graph revealed that Finance had to approve a settlement tolerance before the reconciliation harness could be designed. A scarce production-like environment was also shared with holiday load testing.

The TPM placed both constraints on the graph, negotiated an early decision using sample historical data, and reserved the environment. The team created a recorded-event simulator so service and settlement work could proceed in parallel. Shadow reconciliation began before full operational automation, while any real traffic remained blocked on rollback evidence.

Decision rights: Who owns what?

• Team leads: own task logic and estimates for work in their domains.
• Architecture and engineering owners: decide technical coupling and contract strategies within their authority.
• Product or sponsor: decide scope or milestone trade-offs with business consequences.
• Resource owner: decides allocation of shared people, environments, or facilities.
• Risk and control owners: approve exposure thresholds for integration stages.
• TPM: maintains the cross-program dependency model, tests assumptions, facilitates trade-offs, and highlights the current critical and near-critical paths. The TPM does not rewrite estimates to make a date appear achievable.

I do

I start from the next outcome evidence, a successful reversible traffic ramp, and work backward. I add necessary predecessors, including Finance approval, operational access, representative data, and a rollback exercise. I record an optimistic, planning, and adverse duration where uncertainty matters, plus the basis for each.

I calculate the current path, then run three challenges: the external approval arrives late; the shared environment is unavailable; shadow reconciliation finds a semantic mismatch. The result is not one “accurate” date. It is a map of which interventions protect the outcome.

We do

Together, inspect this claimed dependency: “The settlement team cannot begin until the authorization service is finished.”

Ask what is actually required. The answer is a stable event contract and representative examples, not a deployed service. We split the arrow: contract freeze precedes settlement implementation; service completion precedes integrated runtime testing. A simulator enables parallel progress, but it does not replace consumer-side production evidence.

You do

Create a graph of 10–20 nodes for a current milestone. Include at least one decision, external dependency, shared resource, integration test, and operational-readiness condition. Mark durations as ranges where appropriate. Identify the current critical path, one near-critical path, and two arrows to challenge. Design an integration sequence with an explicit stop or rollback rule at each exposure stage.

Pause & Recall

From memory, define critical path, slack, and coupling. Why can the critical path change without any task being added? Connect to Chapter 14: which interfaces create the strongest arrows in your graph?

Production lens

Refresh the graph at decision closure, material estimate change, interface discovery, resource reallocation, or failed integration. Track dependency health through evidence, not “no update.” For an external dependency, record the contact, commitment, latest safe date, fallback, and escalation threshold. For a shared resource, reserve capacity explicitly. During execution, protect learning events such as integration tests from being repeatedly displaced by component work.

Workplace artifact: Dependency and integration record

# Dependency record
Success endpoint:
Node / owner:
Predecessor and why it is necessary:
Dependency class:
Duration range and basis:
Latest safe decision or delivery date:
Slack / path status:
Fallback or decoupling option:
Evidence of completion:
Escalation threshold:

# Integration stage
Entry evidence:
Exposure:
Observation window:
Stop / rollback rule:
Decision owner:

Chapter compression

Model prerequisite logic before polishing dates. Critical path and slack are properties of a changing model, not permanent labels. Classify and challenge dependencies, reduce unnecessary coupling, and integrate in stages that maximize early learning and reversibility.

Retrieval deck

• Q: What makes a dependency hard? A: The downstream result is impossible without the predecessor, not merely less convenient.
• Q: Why say “current modeled critical path”? A: It depends on estimates, resources, calendars, and known arrows that can change.
• Q: What can make a near-critical path more dangerous? A: Greater uncertainty, external control, scarce resources, or high rework probability.
• Q: How can a simulator change a dependency? A: It can allow earlier implementation or testing against a contract, while not replacing real integration evidence.
• Q: What should every integration stage contain? A: Entry evidence, bounded exposure, observability, a stop or rollback rule, and a decision owner.

Spaced review

• Now: Explain critical path, slack, and near-critical uncertainty aloud.
• +1 day: Redraw the graph and current path from memory.
• +3 days: Challenge two dependency arrows and document what is truly required.
• +7 days: Recalculate the path after one changed estimate or resource assumption.
• +14 days: Compare the modeled constraint with the work that actually limited progress.

Sources and further study

• NASA: Crosscutting Technical Management
• GAO: Technology Readiness Assessment Guide
• PMI: PMBOK Guide
• DORA: Loosely Coupled Teams