A plan is not a real plan if it includes things you “hope” to accomplish. You have to be able to foresee blockers and dependencies. At Amazon, we built systems to ensure all plans included this.
As John Doerr wrote in “Measure What Matters”: “Unanticipated dependencies are the number one blocker of projects.” At Amazon, we recognized this.
Leaders have a choice: they can discover the dependencies for any new initiative either a) before they start building, b) while building, or c) after launch. You will find them (or, more accurately, they will find you) and they become more costly the longer you delay.
This is why we had to answer, “What are the dependencies for project XYZ?” in each PR FAQ document. Similarly each team was required to answer, “What are you organization’s biggest dependencies and what are you doing to reduce them?” in each Annual Operating Plan.
If you don’t have good answers to these questions, your plans won’t get approved. If you’re a leader reviewing a draft of a plan, you learn to probe deeply on this topic to ensure that the team has not missed anything.
When you build something big, you will almost always depend on other internal teams and external partners or regulators.
What happens in most companies is that you get halfway through a project and then realize: “We’re stuck. We didn’t know we needed this other team to change something in order for us to ship.” The result is delay, resolving resource contention, loss of valuable time and perhaps tons of wasted effort if the project is blocked.
And, your whole planning process was a waste of time.
Since we didn’t want any dependencies to surprise us, we required teams to identify these and to determine whether to dependent teams could or could not meet the requirement before the project began. This was done during the OP1 (annual planning) process and in the PR/FAQ process for a new product idea.
In the PR/FAQ, teams must explicitly answer: What are your key dependencies? In the Annual Operating Plan, teams must show which other orgs need to do work for this to succeed and if those teams have committed to doing it.
The upfront work of answering these questions and gaining alignment across teams is time consuming. Many teams avoid it because they want to “go fast,” but skipping it doesn’t save time. It just means you will uncover the dependencies later, which is more costly.
In other cases, teams have so much scar tissue from projects that failed due unresolved dependencies, that they shy away from taking on big problems and opportunities. Instead they limit their work to small, incremental improvements with minor or no dependencies.
(cont. in comments)
