106 lines
3.6 KiB
Markdown
106 lines
3.6 KiB
Markdown
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]]
|