vault backup: 2026-07-23 07:53:56

10 Knowledge/CTO Academy/Project Management/Building My PM System.md

@@ -0,0 +1,103 @@
+# Building My PM System
+Duration: 30–40 minutes
+
+## Definition
+
+Combine the course into a lightweight repeatable system for your team and Monday.com.
+
+This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+
+## 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.
+
+## How It Works
+
+We will examine this concept through four levels:
+
+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.
+
+## Example
+
+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.
+
+The objective is to move from theory to a repeatable management practice.
+
+## How It Fits Into the Bigger Picture
+
+The course builds progressively:
+
+- 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.
+
+## My Company / Real-World Context
+
+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.
+
+The lesson should therefore be applied to an environment where:
+
+- 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
+```
+
+### 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?
+
+## 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.
+
+**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.
+
+## 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.
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+- [[Project Outcome]]
+- [[Definition of Done]]
+- [[Scope]]
+- [[Milestone]]
+- [[Dependencies]]
+- [[Capacity]]
+- [[Risk]]
+- [[Project Health]]
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Capacity and WIP.md

@@ -0,0 +1,103 @@
+# Capacity and WIP
+Duration: 30–40 minutes
+
+## Definition
+
+Plan around real team capacity, operational interruptions, and limits on concurrent work.
+
+This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+
+## 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.
+
+## How It Works
+
+We will examine this concept through four levels:
+
+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.
+
+## Example
+
+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.
+
+The objective is to move from theory to a repeatable management practice.
+
+## How It Fits Into the Bigger Picture
+
+The course builds progressively:
+
+- 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.
+
+## My Company / Real-World Context
+
+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.
+
+The lesson should therefore be applied to an environment where:
+
+- 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
+```
+
+### 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?
+
+## 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.
+
+**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.
+
+## 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.
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+- [[Project Outcome]]
+- [[Definition of Done]]
+- [[Scope]]
+- [[Milestone]]
+- [[Dependencies]]
+- [[Capacity]]
+- [[Risk]]
+- [[Project Health]]
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Closing Projects.md

@@ -0,0 +1,103 @@
+# Closing Projects
+Duration: 30–40 minutes
+
+## Definition
+
+Formally accept outcomes, hand work to operations, document lessons, and close projects.
+
+This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+
+## 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.
+
+## How It Works
+
+We will examine this concept through four levels:
+
+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.
+
+## Example
+
+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.
+
+The objective is to move from theory to a repeatable management practice.
+
+## How It Fits Into the Bigger Picture
+
+The course builds progressively:
+
+- 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.
+
+## My Company / Real-World Context
+
+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.
+
+The lesson should therefore be applied to an environment where:
+
+- 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
+```
+
+### 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?
+
+## 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.
+
+**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.
+
+## 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.
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+- [[Project Outcome]]
+- [[Definition of Done]]
+- [[Scope]]
+- [[Milestone]]
+- [[Dependencies]]
+- [[Capacity]]
+- [[Risk]]
+- [[Project Health]]
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Dependencies.md

@@ -0,0 +1,103 @@
+# Dependencies
+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.
+
+## 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.
+
+## How It Works
+
+We will examine this concept through four levels:
+
+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.
+
+## Example
+
+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.
+
+The objective is to move from theory to a repeatable management practice.
+
+## How It Fits Into the Bigger Picture
+
+The course builds progressively:
+
+- 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.
+
+## My Company / Real-World Context
+
+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.
+
+The lesson should therefore be applied to an environment where:
+
+- 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
+```
+
+### 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?
+
+## 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.
+
+**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.
+
+## 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.
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+- [[Project Outcome]]
+- [[Definition of Done]]
+- [[Scope]]
+- [[Milestone]]
+- [[Dependencies]]
+- [[Capacity]]
+- [[Risk]]
+- [[Project Health]]
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Estimation and Forecasting.md

@@ -0,0 +1,103 @@
+# Estimation and Forecasting
+Duration: 30–40 minutes
+
+## Definition
+
+Build realistic estimates and distinguish estimates, targets, and commitments.
+
+This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+
+## 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.
+
+## How It Works
+
+We will examine this concept through four levels:
+
+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.
+
+## Example
+
+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.
+
+The objective is to move from theory to a repeatable management practice.
+
+## How It Fits Into the Bigger Picture
+
+The course builds progressively:
+
+- 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.
+
+## My Company / Real-World Context
+
+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.
+
+The lesson should therefore be applied to an environment where:
+
+- 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
+```
+
+### 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?
+
+## 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.
+
+**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.
+
+## 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.
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+- [[Project Outcome]]
+- [[Definition of Done]]
+- [[Scope]]
+- [[Milestone]]
+- [[Dependencies]]
+- [[Capacity]]
+- [[Risk]]
+- [[Project Health]]
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Meetings and Follow-up.md

@@ -0,0 +1,103 @@
+# Meetings and Follow-up
+Duration: 30–40 minutes
+
+## Definition
+
+Run project meetings around decisions, blockers, ownership, and next actions.
+
+This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+
+## 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.
+
+## How It Works
+
+We will examine this concept through four levels:
+
+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.
+
+## Example
+
+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.
+
+The objective is to move from theory to a repeatable management practice.
+
+## How It Fits Into the Bigger Picture
+
+The course builds progressively:
+
+- 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.
+
+## My Company / Real-World Context
+
+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.
+
+The lesson should therefore be applied to an environment where:
+
+- 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
+```
+
+### 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?
+
+## 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.
+
+**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.
+
+## 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.
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+- [[Project Outcome]]
+- [[Definition of Done]]
+- [[Scope]]
+- [[Milestone]]
+- [[Dependencies]]
+- [[Capacity]]
+- [[Risk]]
+- [[Project Health]]
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Milestones vs Tasks.md

@@ -0,0 +1,673 @@
+Duration: 30–35 minutes
+
+## Definition
+
+A **task** is a specific piece of work that needs to be performed.
+
+A **milestone** is a significant checkpoint that demonstrates meaningful progress toward the project's outcome.
+
+The distinction matters because managers can easily drown in hundreds of tasks when what they actually need to understand is:
+
+> **Is the project progressing toward its outcome?**
+
+### Task
+
+Examples:
+
+- Configure DNS
+    
+- Create database
+    
+- Implement tracking script
+    
+- Write test cases
+    
+- Review documentation
+    
+- Configure deployment pipeline
+    
+
+Tasks represent **work**.
+
+### Milestone
+
+Examples:
+
+- Infrastructure ready
+    
+- Tracking implementation complete
+    
+- Data validation approved
+    
+- Production launch complete
+    
+- Operational handoff complete
+    
+
+Milestones represent **meaningful states reached by the project**.
+
+---
+
+## Simple Mental Model
+
+Think:
+
+> **Tasks tell the team what to do.**  
+> **Milestones tell the manager where the project is.**
+
+Or:
+
+```text
+TASKS → TASKS → TASKS → MILESTONE
+                         ↓
+TASKS → TASKS → TASKS → MILESTONE
+                         ↓
+TASKS → TASKS → TASKS → PROJECT DONE
+```
+
+You don't necessarily need to know whether task #37 is complete.
+
+You often need to know:
+
+> "Have we reached the production-ready milestone?"
+
+---
+
+## How It Works
+
+Consider a project to implement Umami.
+
+The project could contain dozens of tasks:
+
+```text
+- Create server
+- Configure database
+- Configure DNS
+- Configure SSL
+- Deploy Umami
+- Configure authentication
+- Add tracking script
+- Configure events
+- Test page views
+- Test custom events
+- Validate traffic
+- Compare data
+- Create dashboard
+- Write documentation
+- Train users
+...
+```
+
+All legitimate work.
+
+But imagine you're managing 12 projects.
+
+You cannot effectively manage:
+
+> 15 tasks × 12 projects = 180 individual tasks
+
+And that's a small example.
+
+Instead, you might manage Umami through five milestones:
+
+```text
+1. Infrastructure ready
+          ↓
+2. Tracking implemented
+          ↓
+3. Data validated
+          ↓
+4. Reporting available
+          ↓
+5. Production handoff complete
+```
+
+The project owner manages the tasks required to reach those milestones.
+
+You manage primarily through the milestones.
+
+---
+
+## What Makes a Good Milestone?
+
+A milestone should represent a **meaningful state**, not merely arbitrary progress.
+
+Weak:
+
+> 50% development complete
+
+Better:
+
+> Tracking implementation complete and ready for QA
+
+Weak:
+
+> Worked on infrastructure
+
+Better:
+
+> Production infrastructure ready
+
+Weak:
+
+> Meeting with Product completed
+
+Better:
+
+> Requirements approved by Product
+
+The second versions tell you something important about the project's state.
+
+---
+
+### Milestones should be verifiable
+
+Someone should be able to ask:
+
+> "Did we reach this milestone?"
+
+and get a reasonably objective answer.
+
+For example:
+
+> **Data validation complete**
+
+means agreed validation has occurred and the results were accepted.
+
+Compare that with:
+
+> **Data validation underway**
+
+That's a status, not a milestone.
+
+---
+
+## Example
+
+Let's use your **Pipeline QA d'automatisation** project.
+
+### Outcome
+
+> Critical website functionality can be automatically validated before production releases, reducing manual QA effort and identifying regressions earlier.
+
+### Possible Milestones
+
+**Milestone 1: Requirements approved**
+
+The team agrees on:
+
+- Which user journeys are critical
+    
+- What should be automated
+    
+- What remains manual
+    
+
+---
+
+**Milestone 2: Proof of concept validated**
+
+A small number of tests successfully run automatically.
+
+This reduces an important uncertainty:
+
+> Can our proposed approach actually work?
+
+---
+
+**Milestone 3: Critical test suite complete**
+
+The agreed critical scenarios have been automated.
+
+---
+
+**Milestone 4: Deployment integration complete**
+
+Tests run as part of the agreed deployment workflow.
+
+---
+
+**Milestone 5: QA acceptance complete**
+
+QA validates that the automation meets the agreed requirements.
+
+---
+
+**Milestone 6: Operational handoff complete**
+
+Documentation exists, ownership is established, and the system can move from project work into operations.
+
+Now compare that with:
+
+> Project is 70% complete.
+
+"70%" tells you surprisingly little.
+
+Knowing:
+
+> "The critical test suite is complete, but deployment integration hasn't started"
+
+tells you much more.
+
+---
+
+## How It Fits Into the Bigger Picture
+
+The first four lessons now build directly on each other.
+
+### [[Projects vs Operations]]
+
+> Is this temporary work?
+
+### [[Outcomes and Definition of Done]]
+
+> What are we trying to accomplish, and what counts as finished?
+
+### [[Scope and Scope Creep]]
+
+> What work belongs inside the project?
+
+### [[Milestones vs Tasks]]
+
+> What meaningful checkpoints show us that we're getting there?
+
+Together:
+
+```text
+                    OUTCOME
+                       │
+              Where are we going?
+                       │
+                       ▼
+                    SCOPE
+                       │
+             What are we delivering?
+                       │
+                       ▼
+                 MILESTONES
+                       │
+             How do we know we're
+                making progress?
+                       │
+                       ▼
+                    TASKS
+                       │
+               What needs doing?
+                       │
+                       ▼
+              DEFINITION OF DONE
+```
+
+This order is important.
+
+A common mistake is starting immediately with:
+
+> "Let's create all the Jira tasks."
+
+But you haven't necessarily established what the project is trying to accomplish yet.
+
+---
+
+## My Company / Real-World Context
+
+This concept is particularly relevant to how you should eventually divide responsibility between yourself and your project owners.
+
+You shouldn't need to manage every task performed by your integrators, analysts, QA, or SEO/WCAG person.
+
+The eventual system could look like:
+
+```text
+PROJECT OWNER
+│
+├── Tasks
+├── Detailed sequencing
+├── Day-to-day follow-up
+└── Contributors
+        │
+        ▼
+    MILESTONES
+        │
+        ▼
+       YOU
+```
+
+The project owner should be able to tell you:
+
+> "We're targeting milestone 3 for August 15."
+
+Your job becomes asking:
+
+> "Are we still going to hit August 15?"
+
+rather than:
+
+> "Did Jean complete Jira ticket ABC-234?"
+
+That is a significant difference between **managing projects** and **managing people's task lists**.
+
+---
+
+### Your Monday board
+
+This also gives us our first clue about what might eventually change in Monday.
+
+Your current portfolio has broad timelines.
+
+For example:
+
+```text
+Suppression de Mogador
+April 2026 ───────────────── January 2027
+```
+
+That tells you the project exists for approximately nine months.
+
+But imagine instead seeing:
+
+```text
+Suppression de Mogador
+
+Health: 🟡
+
+Current milestone:
+Replacement synchronization validated
+
+Target:
+September 15
+
+Next milestone:
+Production cutover
+
+Target:
+October 10
+```
+
+Suddenly you can understand the project without opening its entire task list.
+
+We aren't modifying Monday yet, but this is one concept that will eventually influence the design.
+
+---
+
+## Milestones and Dates
+
+Milestones usually have target dates.
+
+This is where something important happens with the problem you've already identified:
+
+> Your projects frequently get interrupted by operations.
+
+Suppose:
+
+```text
+Milestone:
+Tracking implementation complete
+
+Target:
+August 15
+```
+
+August 15 arrives.
+
+The milestone isn't complete because the owner spent eight days dealing with production incidents.
+
+Don't simply change:
+
+> August 15 → August 30
+
+and move on.
+
+The missed milestone contains **management information**.
+
+You want to understand:
+
+> Why did we miss it?
+
+Possible reasons:
+
+- Scope increased
+    
+- Estimate was wrong
+    
+- Operational interruptions
+    
+- Dependency wasn't available
+    
+- Owner didn't execute
+    
+- Requirements weren't clear
+    
+- Priority changed
+    
+- Technical problem appeared
+    
+
+Those causes require completely different management responses.
+
+A milestone isn't only a deadline.
+
+It creates a **checkpoint where reality meets the plan**.
+
+---
+
+## Milestone vs Deadline
+
+They're related but not identical.
+
+A **deadline** says:
+
+> Something must happen by this date.
+
+A **milestone** says:
+
+> The project has reached this meaningful state.
+
+A milestone commonly has a target date:
+
+> **Milestone:** Data validation complete  
+> **Target:** September 30
+
+This gives you both:
+
+**What should be true + when we expect it to be true.**
+
+---
+
+## CTO Perspective
+
+As you move higher in an organization, the level at which you manage should change.
+
+An integrator might think about:
+
+> What code needs to be written today?
+
+A project owner might think about:
+
+> What work needs to happen to reach the next milestone?
+
+You might think about:
+
+> Which projects aren't reaching their milestones?
+
+A CTO might think about:
+
+> Which strategic initiatives aren't delivering their expected outcomes?
+
+Think of it as levels:
+
+```text
+EXECUTIVE
+Outcomes
+    ↑
+YOU
+Projects / Milestones
+    ↑
+PROJECT OWNER
+Milestones / Tasks
+    ↑
+CONTRIBUTOR
+Tasks
+```
+
+This doesn't mean a CTO never looks at a task.
+
+It means they **shouldn't need to manage through tasks under normal circumstances**.
+
+---
+
+### Milestones also create accountability
+
+Suppose one of your project owners says:
+
+> "The project is going well."
+
+Your response can be:
+
+> "What's the next milestone?"
+
+They answer:
+
+> "Data validation."
+
+You ask:
+
+> "When?"
+
+> "August 20."
+
+Then August 20 gives you an objective point to review.
+
+Without milestones, project updates easily become:
+
+> "Still working on it."
+
+> "Making progress."
+
+> "Almost there."
+
+> "Waiting on a couple things."
+
+Those statements are difficult to manage.
+
+---
+
+### Don't create too many milestones
+
+Milestones are supposed to simplify project visibility.
+
+A three-month project probably doesn't need 25 milestones.
+
+If every task becomes a milestone, you've recreated the task list.
+
+A useful starting point might be around **3–7 meaningful milestones** for many of your projects, depending on size and complexity.
+
+The exact number isn't the important part.
+
+Ask:
+
+> **Would I care if this checkpoint wasn't reached?**
+
+If not, it probably doesn't need to be a portfolio-level milestone.
+
+---
+
+### Questions to Ask
+
+- What are the major states this project must pass through before completion?
+    
+- What's the next milestone?
+    
+- Who owns reaching it?
+    
+- What's its target date?
+    
+- What must be true before we consider the milestone achieved?
+    
+- Are we still confident in the target?
+    
+- What could prevent us from reaching it?
+    
+- If we missed it, why?
+    
+- Was the cause scope, capacity, dependency, execution, or something else?
+    
+- Am I managing the project through meaningful checkpoints or micromanaging individual tasks?
+    
+
+---
+
+## Meeting Scenario
+
+**Situation:**
+
+You ask a project owner:
+
+> "How's the project going?"
+
+They respond:
+
+> "Pretty good. We completed about 18 tickets. There's still quite a bit left, but we're making progress."
+
+This gives you very little useful information.
+
+**Possible response:**
+
+> What's the next milestone we're trying to reach, and are we still on track for its target date?
+
+They respond:
+
+> "The next milestone is production data validation on September 15. Development is nearly complete, but we're waiting on DevOps for the production environment, so September 15 is currently at risk."
+
+Now you have something actionable.
+
+The problem isn't:
+
+> "18 tickets completed."
+
+The management information is:
+
+> **Milestone at risk because of a cross-team dependency.**
+
+And because DevOps doesn't report to the project owner, that may be exactly the type of problem that should come to **you**.
+
+---
+
+## Key Takeaways
+
+- **Tasks represent work. Milestones represent meaningful progress.**
+    
+- Project owners should generally manage detailed tasks.
+    
+- Managers should primarily manage projects through outcomes, milestones, risks, and blockers.
+    
+- Good milestones describe verifiable states such as "QA accepted" rather than vague activity such as "working on QA."
+    
+- Milestones should usually have target dates.
+    
+- A missed milestone is useful management information and should trigger understanding of **why** it was missed.
+    
+- Don't automatically move milestone dates without understanding the cause.
+    
+- Too many milestones defeats their purpose.
+    
+- Milestones help you manage multiple projects without micromanaging every task.
+    
+- As leadership responsibility increases, management should increasingly move from **tasks → milestones → outcomes**.
+    
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+    
+- [[Outcomes and Definition of Done]]
+    
+- [[Scope and Scope Creep]]
+    
+- [[Milestones vs Tasks]]
+    
+- [[Dependencies]]
+    
+- [[Capacity and WIP]]
+    
+- [[Project Health]]
+    
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Ownership and Delegation.md

@@ -0,0 +1,103 @@
+# Ownership and Delegation
+Duration: 30–40 minutes
+
+## Definition
+
+Make project ownership clear and develop team members who can drive projects.
+
+This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+
+## 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.
+
+## How It Works
+
+We will examine this concept through four levels:
+
+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.
+
+## Example
+
+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.
+
+The objective is to move from theory to a repeatable management practice.
+
+## How It Fits Into the Bigger Picture
+
+The course builds progressively:
+
+- 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.
+
+## My Company / Real-World Context
+
+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.
+
+The lesson should therefore be applied to an environment where:
+
+- 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
+```
+
+### 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?
+
+## 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.
+
+**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.
+
+## 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.
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+- [[Project Outcome]]
+- [[Definition of Done]]
+- [[Scope]]
+- [[Milestone]]
+- [[Dependencies]]
+- [[Capacity]]
+- [[Risk]]
+- [[Project Health]]
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Portfolio Management.md

@@ -0,0 +1,103 @@
+# Portfolio Management
+Duration: 30–40 minutes
+
+## Definition
+
+Manage the collection of projects as a system rather than independently.
+
+This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+
+## 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.
+
+## How It Works
+
+We will examine this concept through four levels:
+
+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.
+
+## Example
+
+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.
+
+The objective is to move from theory to a repeatable management practice.
+
+## How It Fits Into the Bigger Picture
+
+The course builds progressively:
+
+- 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.
+
+## My Company / Real-World Context
+
+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.
+
+The lesson should therefore be applied to an environment where:
+
+- 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
+```
+
+### 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?
+
+## 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.
+
+**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.
+
+## 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.
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+- [[Project Outcome]]
+- [[Definition of Done]]
+- [[Scope]]
+- [[Milestone]]
+- [[Dependencies]]
+- [[Capacity]]
+- [[Risk]]
+- [[Project Health]]
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Prioritization.md

@@ -0,0 +1,103 @@
+# Prioritization
+Duration: 30–40 minutes
+
+## Definition
+
+Decide what should be worked on now when everything appears important.
+
+This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+
+## 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.
+
+## How It Works
+
+We will examine this concept through four levels:
+
+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.
+
+## Example
+
+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.
+
+The objective is to move from theory to a repeatable management practice.
+
+## How It Fits Into the Bigger Picture
+
+The course builds progressively:
+
+- 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.
+
+## My Company / Real-World Context
+
+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.
+
+The lesson should therefore be applied to an environment where:
+
+- 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
+```
+
+### 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?
+
+## 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.
+
+**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.
+
+## 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.
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+- [[Project Outcome]]
+- [[Definition of Done]]
+- [[Scope]]
+- [[Milestone]]
+- [[Dependencies]]
+- [[Capacity]]
+- [[Risk]]
+- [[Project Health]]
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Project Health.md

@@ -0,0 +1,103 @@
+# Project Health
+Duration: 30–40 minutes
+
+## Definition
+
+Use evidence to classify projects as healthy, at risk, or off track.
+
+This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+
+## 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.
+
+## How It Works
+
+We will examine this concept through four levels:
+
+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.
+
+## Example
+
+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.
+
+The objective is to move from theory to a repeatable management practice.
+
+## How It Fits Into the Bigger Picture
+
+The course builds progressively:
+
+- 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.
+
+## My Company / Real-World Context
+
+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.
+
+The lesson should therefore be applied to an environment where:
+
+- 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
+```
+
+### 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?
+
+## 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.
+
+**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.
+
+## 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.
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+- [[Project Outcome]]
+- [[Definition of Done]]
+- [[Scope]]
+- [[Milestone]]
+- [[Dependencies]]
+- [[Capacity]]
+- [[Risk]]
+- [[Project Health]]
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Risk Management.md

@@ -0,0 +1,103 @@
+# Risk Management
+Duration: 30–40 minutes
+
+## Definition
+
+Identify, assess, mitigate, and monitor risks before they become project problems.
+
+This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+
+## 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.
+
+## How It Works
+
+We will examine this concept through four levels:
+
+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.
+
+## Example
+
+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.
+
+The objective is to move from theory to a repeatable management practice.
+
+## How It Fits Into the Bigger Picture
+
+The course builds progressively:
+
+- 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.
+
+## My Company / Real-World Context
+
+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.
+
+The lesson should therefore be applied to an environment where:
+
+- 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
+```
+
+### 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?
+
+## 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.
+
+**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.
+
+## 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.
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+- [[Project Outcome]]
+- [[Definition of Done]]
+- [[Scope]]
+- [[Milestone]]
+- [[Dependencies]]
+- [[Capacity]]
+- [[Risk]]
+- [[Project Health]]
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Status Reporting.md

@@ -0,0 +1,103 @@
+# Status Reporting
+Duration: 30–40 minutes
+
+## Definition
+
+Communicate project status concisely to managers, executives, and stakeholders.
+
+This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+
+## 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.
+
+## How It Works
+
+We will examine this concept through four levels:
+
+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.
+
+## Example
+
+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.
+
+The objective is to move from theory to a repeatable management practice.
+
+## How It Fits Into the Bigger Picture
+
+The course builds progressively:
+
+- 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.
+
+## My Company / Real-World Context
+
+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.
+
+The lesson should therefore be applied to an environment where:
+
+- 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
+```
+
+### 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?
+
+## 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.
+
+**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.
+
+## 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.
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+- [[Project Outcome]]
+- [[Definition of Done]]
+- [[Scope]]
+- [[Milestone]]
+- [[Dependencies]]
+- [[Capacity]]
+- [[Risk]]
+- [[Project Health]]
+- [[Portfolio Management]]

10 Knowledge/CTO Academy/Project Management/Table of Content.md

@@ -0,0 +1,73 @@
+# Project Management
+
+## Course Progress
+
+- [x] [[Projects vs Operations]]
+- [x] [[Outcomes and Definition of Done]]
+- [x] [[Scope and Scope Creep]]
+- [x] [[Milestones vs Tasks]]
+- [ ] [[Dependencies]]
+- [ ] [[Estimation and Forecasting]]
+- [ ] [[Prioritization]]
+- [ ] [[Capacity and WIP]]
+- [ ] [[Risk Management]]
+- [ ] [[Project Health]]
+- [ ] [[Status Reporting]]
+- [ ] [[Meetings and Follow-up]]
+- [ ] [[Ownership and Delegation]]
+- [ ] [[Portfolio Management]]
+- [ ] [[Closing Projects]]
+- [ ] [[Building My PM System]]
+
+---
+
+## Learning Path
+
+### Foundation
+
+1. [[Projects vs Operations]]
+2. [[Outcomes and Definition of Done]]
+3. [[Scope and Scope Creep]]
+4. [[Milestones vs Tasks]]
+
+### Planning and Delivery
+
+5. [[Dependencies]]
+6. [[Estimation and Forecasting]]
+7. [[Prioritization]]
+8. [[Capacity and WIP]]
+9. [[Risk Management]]
+
+### Managing Projects
+
+10. [[Project Health]]
+11. [[Status Reporting]]
+12. [[Meetings and Follow-up]]
+13. [[Ownership and Delegation]]
+
+### Managing the Portfolio
+
+14. [[Portfolio Management]]
+15. [[Closing Projects]]
+
+### Build the System
+
+16. [[Building My PM System]]
+
+---
+
+## End Goal
+
+Build a repeatable project management system where:
+
+- Every project has a clear outcome and Definition of Done.
+- Scope and major milestones are agreed before commitment.
+- A project owner within the team drives each project.
+- Project owners maintain their own project information.
+- Dependencies, risks and blockers become visible early.
+- Estimates account for actual capacity and operational interruptions.
+- Scope changes result in explicit trade-offs.
+- I manage through milestones and outcomes rather than individual tasks.
+- Project health tells me where my intervention is required.
+- The portfolio shows what the team has committed to and whether we have capacity for more work.
+- Monday.com becomes a management tool rather than a project list that nobody updates.