Why Projects Break During the Handoffs Nobody Owns

Most project managers can produce a dependency list. Far fewer can say, for any line on that list, which person on their own team is watching it, and on what date that person will ask for written confirmation that the upstream work is still on schedule.

That distance, between listing a dependency and managing one, is where a large share of late projects actually break. The schedule was not wrong. The estimates were not wrong. Something agreed in a hallway, or buried in an email thread from 3 months earlier, quietly stopped being true, and nobody found out until the week the dependent work was supposed to start.

A dependency is any relationship where one piece of work cannot start, continue, or finish until something else happens first: another task, a decision, an approval, a vendor delivery, a person coming back from leave. Teams rarely miss them because they are hard to see during planning. They miss them because a dependency raised in a kickoff and assigned to nobody is a conversation, and conversations decay.

There is a second reason, more cultural than technical. Dependency mapping carries the smell of governance theatre, the kind of artifact produced to satisfy a committee and then never opened again, so teams treat it as documentation rather than as an early warning instrument. Used properly it is closer to the wiring diagram of a house. Invisible while everything works, and the only thing worth having the moment something starts to smell like smoke.

Four Relationships, Two Attributes

The precedence diagramming method, documented in PMI's scheduling practice and in earlier editions of the PMBOK Guide, describes four logical relationships between activities. The distinction is practical rather than academic, because each one fails in a different way and gives a different amount of warning.

• Finish to Start (FS) means the successor cannot begin until the predecessor is complete, which covers most contractual handoffs, such as integration testing that cannot start until a vendor delivers a working interface.
• Start to Start (SS) means the successor cannot begin until the predecessor has begun, which is common in workstreams that look independent on a Gantt chart and are in fact synchronized at the front end.
• Finish to Finish (FF) means the successor cannot complete until the predecessor completes, which produces blockages in the middle of work that still looks productive right up to the moment it stalls.
• Start to Finish (SF) means the predecessor cannot finish until the successor starts, rare outside cutovers, shift handovers, and legacy system retirements, where it quietly decides whether a transition is safe.

The PMBOK Guide also classifies dependencies by attribute, and those attributes matter more than the relationship type for anyone deciding where to spend attention. A dependency is mandatory when physics, contract, or regulation leaves no alternative, and discretionary when the team chose a sequence for good reasons and could choose differently under pressure. It is internal when the upstream work sits inside the project team, and external when it sits with a vendor, a regulator, or another department with its own backlog and its own stressed manager.

The combination worth obsessing over is external and mandatory. Internal work is visible in a standup, a board, a hallway conversation. External work is visible only when somebody asks, and the answer arrives filtered through an account manager who has an incentive to sound calm.

From Acknowledgement to Monitoring

In Normal Accidents (1984), the sociologist Charles Perrow described tightly coupled systems as those with no slack between components, where a small local failure propagates before anyone can intervene. Most project schedules are considerably more tightly coupled than the people who built them believe, because every compression of the timeline removes exactly the buffer that would have absorbed a late handoff.

The collapse follows a predictable sequence. The dependency exists but is undocumented, then nobody is named as its owner, then no trigger date is set for confirming it, and by the time the delay announces itself the downstream work has already lost the time it needed to adapt.

Human optimism accelerates all of this. Kahneman and Tversky named the planning fallacy in 1979, the systematic tendency to underestimate the time a task will take even with direct experience of the same task going long before. Optimistic estimates combined with untracked handoffs produce a project that looks healthy for months and then meets its accumulated delay during integration and testing, which is precisely the phase with the least remaining room to recover.

Four practices convert acknowledgement into monitoring, and none of them require a tool purchase.

Name an owner on your own side. For every external dependency, one person on the project team is responsible for tracking the other side's progress and raising the flag when it drifts. Nobody can own work performed by another organization, though anyone can own the monitoring of it, and that ownership is what most projects never assign.

Set a proximity alarm at planning time. A proximity alarm is a date on the calendar, typically 2 to 3 weeks before the due date, when the owner obtains explicit confirmation that the commitment still holds. What counts is a confirmed status, since an assumption recorded as a fact is exactly what these alarms exist to catch. Anything short of a clear yes triggers the contingency plan immediately, while the runway to use it still exists.

Keep a log with fields that force precision. A causal description ("because the vendor must complete the interface before integration testing can begin, our test start depends on delivery by 30 April") makes the risk legible to anyone skimming, where the phrase "API integration" hides it. The log needs the relationship type and attributes, the upstream owner and the dependency owner, the due date and the alarm date, a status limited to on track, at risk, blocked, or resolved, the impact expressed in days and in percentage of remaining buffer, and one sentence describing the contingency.

Review weekly and look for concentration. A flat list of 50 dependencies hides the shape of the risk, while a sketch of deliverables as nodes and dependencies as arrows shows immediately which node has 6 arrows pointing into it. Those convergence points deserve the earliest alarms and the most developed fallback plans, because a slip there sets several workstreams on fire at the same moment.

Escalation follows the same discipline. Reporting that a vendor is late produces anxiety and a request for more detail, while reporting that the delay is 8 days and consumes 35 percent of the remaining buffer to the integration milestone produces a decision, which is the actual point of escalating.

None of this removes delays. It converts an unpleasant discovery 4 weeks before launch into a manageable decision taken much earlier, when options still cost less than apologies. For a project manager early in their career, the return on this practice is unusually high relative to its cost: one workshop that asks what must be finished first, what must run in parallel, and who outside the room holds a key, a named owner for every external link, and an alarm date written into the calendar before anyone feels nervous enough to need it.