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

2026-07-23 07:53:56 -04:00
parent 72b42ebcaf
commit 1033a565cb
14 changed files with 1982 additions and 0 deletions
@@ -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]]
@@ -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]]
@@ -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]]
@@ -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]]
@@ -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]]
@@ -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]]
@@ -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]]
@@ -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]]
@@ -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]]
@@ -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]]
@@ -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]]
@@ -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]]
@@ -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]]
@@ -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.