Project dependencies and scheduling

The critical path is the sequence of activities linked by dependencies whose cumulative duration determines the project's end date. In other words, any delay on a critical-path activity mechanically pushes back delivery, whereas a delay on an activity off the critical path can be absorbed by the available float. This concept, formalized by the Critical Path Method (CPM) in the 1950s, remains the first tool for reading a schedule. It rests on a simple idea: identify the chain of activities that admits no float, because that chain governs the final delivery date. In a real project, the critical path is not fixed: it shifts with each rescheduling, disruption, and arbitration choice. An activity that is non-critical today may become critical tomorrow if the float protecting it is consumed elsewhere. Following it therefore requires regular recalculation, not a one-off reading.

Manual dependency mapping hits its limit around a few hundred activities: beyond that, the probability of missing a link or introducing an error becomes too high for the analysis to remain reliable. This is the main reason so many impact analyses simply never get done on large projects. A pragmatic discipline yields good results: work upward from the final deliverables back to their upstream conditions, rather than moving forward chronologically. This reverse reading brings out the dependency chains that a sequential reading buries, and it forces the useful question: "what has to be true for this deliverable to exist?" To structure the mapping, a dependency matrix (often called a DSM, for Design Structure Matrix) is a proven tool. Each row and each column carries the same activities or deliverables; a cross at the intersection signals a dependency. The matrix makes loops visible, which indicate a sequencing problem, and forces an exhaustive reading: you cannot "forget" a cell. It also lets you type the dependencies as the matrix is filled in, distinguishing technical links (impossible to bypass), resource links (shared allocation), preferential sequencing links (organizational choices), and external dependencies (supplier deliveries, client decisions, contractual milestones) that fall outside the project team's direct control. This typology then illuminates the real room to maneuver during reschedulings. In practice, the matrix is built workshop by workshop, by interviewing work-package leads, then consolidated and maintained throughout the project.

A schedule buffer is a time margin explicitly reserved to absorb uncertainty, distinct from the implicit float that the critical path reveals after the fact. The principle: make the schedule's protection visible and debatable, rather than leaving it diffuse and invisible inside individual estimates. Three placements are widely accepted. The project buffer, placed at the end of the critical path, protects the contractual delivery date against the accumulation of drift. Feeding buffers, placed upstream of the junctions where a secondary chain joins the critical path, prevent a lateral delay from becoming critical. Resource buffers, less common, reserve the availability of a critical resource expected on a specific date. Sizing, however, does not enjoy the same consensus. The CCPM method (Critical Chain Project Management), which is part of the Theory of Constraints (TOC) formalized by Eliyahu Goldratt, proposes proportional rules: 50% of the protected chain, often reduced to 33% in practice. Other approaches prefer sizing through activity-by-activity risk analysis. The real pitfall is not which method you pick, but the absence of an explicit buffer: without one, each individual estimate carries its own hidden margin, less efficient overall, and invisible to project control.