Map the Dependencies
What has to be true for this to work? And what if it isn't?
Before committing to a plan, write: What has to be true for this to work? List every assumption, every dependency, every condition. Circle the ones you don't control. For each circled item, ask: What's my contingency if this doesn't hold? If more than two critical dependencies are outside your control with no contingency, the plan is fragile.
You're about to commit significant resources to a plan and want to stress-test its weak points before launching.
The plan is simple, reversible, and cheap enough that a detailed dependency map would be overkill.
Why it works
Plans fail at their assumptions, not their logic. Every unexamined assumption is a hidden dependency — and hidden dependencies are where "surprises" come from. Making them explicit before committing is the difference between a plan and a wish.
Every plan is a chain of assumptions. The market will respond this way. The team will deliver on time. The technology will work. Each assumption is a dependency — a condition that must hold for the plan to succeed. Plans don’t fail because the logic is wrong. They fail because an assumption proves false and nobody prepared for that. The dependency map makes the invisible visible. When you see that your plan requires five things to go right, three of which you don’t control, the fragility is obvious. That’s not a reason to abandon the plan — it’s a reason to build contingencies for the dependencies you can’t guarantee.