Your status review looked clean. Scope was locked. The timeline had a little slack. The budget was on plan. You reported green with a clear conscience, because the three things you are trained to watch were all fine.
Then the integration you needed from the platform team slipped two weeks, because their sprint got reprioritized and nobody told you.
Or the vendor who owns one API pushed their release. Or the shared environment you were counting on for testing got booked by another project first.
None of that showed up in scope, time, or cost until it had already cost you time.
And when the date moved, the question landed on you: how did you not see this coming?
Here is the uncomfortable part. You were watching the project. You just were not watching the part of it that you do not control. And that part had no owner.
The Shift
The iron triangle tells you a project is bounded by three constraints: scope, time, and cost. Move one and the others move. It is a good model, and it is incomplete, because it quietly assumes every piece of the work is yours to move.
Most delivery work is not. It runs on dependencies: another team's component, a vendor's timeline, a platform you share, an approval that lives in someone else's queue.
Those dependencies are a real constraint. They can sink a date faster than any scope change. But they sit outside the triangle, so they get treated as a risk footnote instead of a first-class limit on what you can deliver.
So add the fourth side.
Scope, time, cost, and dependency load.
The fourth side behaves differently from the other three, which is exactly why it needs its own slot: you cannot directly move it, only the team or vendor who owns it can.
That does not make it someone else's problem. It makes it the constraint you have to manage by influence instead of by authority, which is harder, which is why it needs to be visible and owned rather than assumed.
The System
Give the fourth side the same treatment the other three already get: make it visible, make it measured, make it owned. That is a Dependency Load Map, and it has four moves.
List every dependency. Not the big ones you remember under pressure, all of them: every cross-team component, vendor deliverable, shared environment, and external approval your plan is riding on. If your project needs it and cannot produce it itself, it goes on the map.
Rate each one's fragility. Two questions: how likely is this to slip, and how much would it hurt if it did. A stable internal team on a low-stakes item is low fragility. A vendor with a history of missed dates sitting on your critical path is high. You are not trying to be precise. You are trying to sort the list so the dangerous ones stand out.
Assign one named owner to each. A person, not a team. The owner's job is not to do the dependency's work. It is to know its status and to raise a hand early when it wobbles. A dependency owned by "the platform team" is owned by no one.
Set a check-in cadence sized to fragility. High-fragility dependencies get a real touchpoint every week. Low-fragility ones can ride a monthly glance. The point is that the check is scheduled, not left to whenever someone remembers.
Then put the map where scope, time, and cost already live. Review it in the same meeting, on the same rhythm. The fourth side stops being the thing you discover after it breaks and becomes the thing you were already watching.
The Asset
The asset for this issue is the Dependency Load Map.
It is a one-page working map, not a checklist. It gives you a row for each dependency with columns for the owning team or vendor, the named owner, a fragility rating, the next check-in date, and what stays blocked if it slips. Fill it in once, review it on cadence, and the dependencies you cannot control stop being the ones that surprise you.
You'll find the download button in The Move section below.
The AI Assist
One practical workflow here: turn a project plan into a first-draft dependency map. Use it when you have a plan or a set of meeting notes and you do not want to hunt for every dependency by hand.
Use this prompt:
You are helping me surface project dependencies. Below is a project plan (or meeting notes). Pull out every item my project depends on that another team, vendor, or shared system has to deliver.
For each one, give me: the dependency, the team or vendor that owns the work, the named owner if the text states one, and a note if no owner is named. Flag every dependency that has no named owner and every one with no scheduled check-in.
Return it as a table, sorted with the ones most likely to be on a critical path at the top. Do not invent owners or dates that are not in the text.
Plan or notes: [paste here]
AI is good at finding the dependencies you glossed over and catching the ones with no owner. You still set the fragility rating and assign the owner, because those are judgment calls that need your read of the politics, not just the plan.
The Move
Take the project constraint review you already run most often. This week, add the fourth side to it: list your dependencies, rate each one's fragility, and assign a named person to each.
Start with your highest-fragility dependency and make sure it has an owner and a check-in date before you close the review.
The Dependency Load Map is free for Execution Signal subscribers. Enter your email and it lands in your inbox instantly, together with the Starter Pack.
Reply prompt: Which dependency on your project right now has no single named owner, and what breaks first if it slips?
P.S. New here? Subscribe free and the Execution Signal Starter Pack lands in your inbox: get the Starter Pack.