3.6 KiB
Duration: 30--40 minutes
Definition
A dependency is something a project needs but does not fully control. It may be another task, person, team, vendor, environment, approval, decision, data source, or access requirement. A blocker is a dependency that is currently preventing progress.
Simple Mental Model
What must happen outside this work before we can reach the next milestone?
How It Works
Project owners should identify dependencies early, record who owns them and when they are needed, follow up before they become blockers, and escalate when authority or priority is required.
Dependency types
- Internal: another task or contributor inside the project
- Cross-team: Product, DevOps, Security, IT, Finance, etc.
- External: vendor, partner, contractor
- Decision: approval or choice required before work can proceed
A dependency is not automatically a risk. "DevOps must create the environment" is a dependency. "DevOps may not have capacity by August 15" is a risk.
Example
For an analytics implementation:
Dependency Owner Needed by Impact if late
Production DevOps Aug 15 QA cannot start environment
Security review Security Aug 20 Production blocked
Tracking Product/Data Aug 5 Implementation requirements unclear
In your environment this matters because project owners frequently depend on Product, DevOps, Security, vendors, QA, and other departments. The owner may not control those teams, but still owns making the dependency visible and following it.
CTO Perspective
You should not personally chase every dependency. The owner manages normal follow-up. You intervene when priorities conflict, a committed milestone is threatened, the owner lacks authority, or the same bottleneck repeatedly affects projects.
Questions to Ask
- What does the next milestone depend on?
- Who owns it?
- When is it needed?
- Has the other team actually committed?
- What happens if it is late?
- When should this be escalated?
Meeting Scenario
Situation: The owner says Friday's milestone will slip because DevOps has not created the environment.
Possible response:
When did we identify the dependency, what date did DevOps commit to, and when did we know it was at risk? If you've already followed up and the milestone is threatened, I'll help escalate it.
Key Takeaways
- Dependencies are things the project needs but does not fully control.
- Blockers are dependencies actively preventing progress.
- Identify dependencies from milestones before they are needed.
- Project owners manage routine follow-up.
- Managers handle cross-team priority and authority escalation.
- Repeated dependency failures may reveal an organizational bottleneck.
How It Fits Into the Bigger Picture
This lesson builds on Projects vs Operations, [[Outcomes and Definition of Done]], Scope and Scope Creep, and Milestones vs Tasks. It prepares the project system to become more predictable and scalable.
Related Concepts
- Milestones vs Tasks
- Estimation and Forecasting
- Prioritization
- Capacity and WIP
- Risk Management
- Project Health
- Portfolio Management