amadou/SecondBrain
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2026-07-23 14:57:54

Browse Source
This commit is contained in:
amadou
2026-07-23 14:57:54 +02:00
parent 0527e561b3
commit 8526cf4212
12 changed files with 1084 additions and 799 deletions
Download Patch File Download Diff File Expand all files Collapse all files
10 Knowledge/CTO Academy/Project Management/Dependencies.md
+74 -68
View File
@@ -1,101 +1,107 @@
Duration: 30–40 minutes
Duration: 30--40 minutes
## Definition
Identify work, people, teams, vendors, and decisions that can block delivery.
This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
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
The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage.
**What must happen outside this work before we can reach the next
milestone?**
## How It Works
We will examine this concept through four levels:
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.
1. What the concept means.
2. How a project owner should use it.
3. How you should review or challenge it as the manager.
4. How it should eventually appear in your project-management system.
### Dependency types
## Example
- 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
The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security.
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.
The objective is to move from theory to a repeatable management practice.
### Example
## How It Fits Into the Bigger Picture
For an analytics implementation:
The course builds progressively:
-----------------------------------------------------------------------
Dependency Owner Needed by Impact if late
----------------- ----------------- ----------------- -----------------
Production DevOps Aug 15 QA cannot start
environment
- Project vs operations establishes what kind of work we are managing.
- Outcomes and Definition of Done establish what success means.
- Scope establishes the project's boundaries.
- Milestones establish meaningful progress.
- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable.
- Status reporting, meetings, ownership, and portfolio management make the system scalable.
- Closing and the final PM system turn the concepts into an operating method.
Security review Security Aug 20 Production
blocked
## My Company / Real-World Context
Tracking Product/Data Aug 5 Implementation
requirements unclear
-----------------------------------------------------------------------
Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security.
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.
The lesson should therefore be applied to an environment where:
### CTO Perspective
- Project owners are usually members of your own team rather than dedicated PMs.
- Operational work regularly interrupts project work.
- Product and IT are important cross-functional partners.
- You need portfolio-level visibility without personally maintaining every task.
- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate.
## CTO Perspective
The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes.
The expected progression is:
```text
Contributor → manages tasks
Project Owner → drives milestones and delivery
Manager → manages projects, priorities, risks and escalation
Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs
```
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 information do I need to make a management decision?
- What should the project owner be responsible for maintaining?
- What requires my intervention?
- What can be standardized across every project?
- Is the process helping delivery, or merely creating administration?
- 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
### Meeting Scenario
**Situation:**
A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome.
**Situation:** The owner says Friday's milestone will slip because
DevOps has not created the environment.
**Possible response:**
> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me.
> 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
### Key Takeaways
- The purpose of project management is predictable delivery, not documentation for its own sake.
- Project owners should own increasingly more of the planning and maintenance.
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
- Every concept learned should eventually contribute to one lightweight common project template.
- The final system should make exceptions and problems visible without requiring you to inspect every task.
- 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
- [[Projects vs Operations]]
- [[Outcomes and Definition of Done]]
- [[Scope and Scope Creep]]
- [[Milestones vs Tasks]]
- [[Dependencies]]
- [[Capacity and WIP]]
- [[Risk Management]]
- [[Project Health]]
- [[Portfolio Management]]
- [[Milestones vs Tasks]]
- [[Estimation and Forecasting]]
- [[Prioritization]]
- [[Capacity and WIP]]
- [[Risk Management]]
- [[Project Health]]
- [[Portfolio Management]]