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

2026-07-23 14:57:54 +02:00
parent 0527e561b3
commit 8526cf4212
12 changed files with 1084 additions and 799 deletions
@@ -1,103 +1,270 @@
 # Building My PM System
-Duration: 30–40 minutes
+
 Duration: 30--40 minutes
 ## Definition
-Combine the course into a lightweight repeatable system for your team and Monday.com.
+A **project management system** is the repeatable set of roles,
 information, routines, and tools used to move work from proposal to
 completion.
-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+The goal is not to recreate a heavy PMO. It is to build a lightweight
 operating system that makes ownership, commitments, risks, and outcomes
 visible.
 ## 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.
+> **The owner manages the project. You manage the portfolio and
 > exceptions. The system keeps both visible.**
 If the system depends on you remembering to chase every project, it is
 not yet a system.
 ## How It Works
-We will examine this concept through four levels:
+### 1. Standard Project Brief
-1. What the concept means.
+``` markdown
-2. How a project owner should use it.
+# Project Name
-3. How you should review or challenge it as the manager.
+
-4. How it should eventually appear in your project-management system.
+## Owner
 ## Outcome
 What should be different when this succeeds?
 ## Business Value
 Why are we doing it?
 ## Definition of Done
 - [ ]
 - [ ]
 ## Scope
 ### In Scope
 -
 ### Out of Scope
 -
 ## Milestones
 | Milestone | Target | Status |
 |---|---|---|
 ## Dependencies
 | Dependency | Owner | Needed By | Status |
 |---|---|---|---|
 ## Risks
 | Risk | Probability | Impact | Response | Owner |
 |---|---|---|---|---|
 ## Current Health
 Green / Yellow / Red
 ## Current Status
 What changed? What is the next milestone?
 ## Decisions / Help Needed
 -
 ## Scope Changes
 | Date | Change | Impact | Decision |
 |---|---|---|---|
 ```
 ### 2. Clear Roles
 **You**
 -   Approve/prioritize
 -   Challenge briefs
 -   Confirm commitments
 -   Manage portfolio/capacity
 -   Resolve priority conflicts
 -   Escalate cross-team blockers
 -   Coach owners
 **Project owner**
 -   Draft/maintain brief
 -   Drive milestones
 -   Coordinate contributors
 -   Manage dependencies
 -   Surface risks and scope changes
 -   Keep status current
 -   Escalate
 -   Drive closure
 ### 3. Portfolio View
 Monday.com becomes the portfolio source of truth.
 Emphasize:
 -   Project
 -   Owner
 -   Priority
 -   Portfolio state
 -   Health
 -   Next milestone
 -   Milestone target
 -   Major blocker/dependency
 -   Overall timeline
 Detailed execution can remain in subitems/Jira where appropriate.
 ### 4. Management Cadence
 **During the week:** update material changes when they happen.
 **Weekly owner update:** health, milestone, forecast, blockers/risks,
 scope changes, help needed.
 **Weekly/biweekly portfolio review:** Yellow/Red, milestones, priority
 conflicts, capacity, new projects, closures.
 **Monthly:** Are we doing the right projects? Is WIP too high? Where is
 operational load hurting delivery? Which recurring blockers need
 systemic fixes?
 ### 5. Management by Exception
 ``` text
 GREEN  → owner manages
 YELLOW → manager pays attention/coaches
 RED    → manager intervenes/escalates
 ```
 ## 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.
+  Project         Owner   Priority   Health   Next Milestone               Target
  --------------- ------- ---------- -------- ---------------------------- --------
  Umami           A       High       Yellow   Production validation        Aug 20
  QA Automation   B       Medium     Green    POC accepted                 Sep 5
  Mogador         C       High       Red      Replacement sync validated   Aug 15
  RAG POC         D       Low        Green    POC demo                     Nov 30
-The objective is to move from theory to a repeatable management practice.
+You inspect Mogador first, then Umami. The system tells you where
 management attention is required.
 ## How It Fits Into the Bigger Picture
-The course builds progressively:
+``` text
-
+Projects vs Operations
- Project vs operations establishes what kind of work we are managing.
+        ↓
- Outcomes and Definition of Done establish what success means.
+Outcome + DoD
- Scope establishes the project's boundaries.
+        ↓
- Milestones establish meaningful progress.
+Scope
- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable.
+        ↓
- Status reporting, meetings, ownership, and portfolio management make the system scalable.
+Milestones
- Closing and the final PM system turn the concepts into an operating method.
+        ↓
 Dependencies
        ↓
 Estimate / Forecast
        ↓
 Priority
        ↓
 Capacity / WIP
        ↓
 Risks
        ↓
 Health
        ↓
 Status / Meetings
        ↓
 Ownership
        ↓
 Portfolio
        ↓
 Closure
 ```
 ## 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.
+Your original problem was that Monday contained projects and timelines,
 but you rarely returned to update it.
-The lesson should therefore be applied to an environment where:
+The answer is not simply that you need to remember Monday more.
- Project owners are usually members of your own team rather than dedicated PMs.
+> **Project owner maintains project truth.**
- Operational work regularly interrupts project work.
+
- Product and IT are important cross-functional partners.
+You maintain:
- 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.
+> **Portfolio truth.**
 Owners draft briefs, propose timelines, maintain milestones, and surface
 exceptions. You validate, challenge, prioritize, coach, and escalate.
 ## CTO Perspective
-The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes.
+This is the transition from personal competence to management
 capability.
-The expected progression is:
+The test is not:
-```text
+> Do I know what is happening because I attended every meeting?
-Contributor → manages tasks
+
-Project Owner → drives milestones and delivery
+It is:
-Manager → manages projects, priorities, risks and escalation
+
-Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs
+> Can I see what needs attention, trust the information, and intervene
-```
+> at the right level?
 ### Questions to Ask
- What information do I need to make a management decision?
+-   Does every project have one owner?
- What should the project owner be responsible for maintaining?
+-   Is the outcome clear?
 -   Is DoD explicit?
 -   Is scope bounded?
 -   What is the next milestone?
 -   Are dependencies and risks visible?
 -   Is the forecast based on real capacity?
 -   Is health trustworthy?
 -   What requires my intervention?
- What can be standardized across every project?
+-   Are we starting too much?
- Is the process helping delivery, or merely creating administration?
+-   Which projects can close?
 -   Is Monday helping decisions or merely storing information?
 ## Meeting Scenario
-**Situation:**
+**Situation:** You open Monday after two weeks and several projects are
-
+stale because you are still expected to update everything.
 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.
+> The problem isn't that I need to remember Monday more often. Each
 > project needs an owner responsible for keeping health, milestones,
 > risks, and forecast current. My responsibility is to review the
 > portfolio, challenge the information, and intervene where needed.
 ## Key Takeaways
- The purpose of project management is predictable delivery, not documentation for its own sake.
+-   Build one lightweight common project method.
- Project owners should own increasingly more of the planning and maintenance.
+-   Owners maintain project-level information.
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
+-   You maintain priorities, capacity, portfolio health, and escalation.
- Every concept learned should eventually contribute to one lightweight common project template.
+-   Monday becomes the portfolio source of truth.
- The final system should make exceptions and problems visible without requiring you to inspect every task.
+-   Use a standard brief.
 -   Use a recurring cadence so the system does not depend on memory.
 -   Manage by exception.
 -   Limit WIP.
 -   Close projects deliberately.
 -   The end goal is repeatable management capability and visible
    organizational outcomes.
 ## Related Concepts
- [[Projects vs Operations]]
+-   \[\[Projects vs Operations\]\]
- [[Project Outcome]]
+-   \[\[Outcomes and Definition of Done\]\]
- [[Definition of Done]]
+-   \[\[Scope and Scope Creep\]\]
- [[Scope]]
+-   \[\[Milestones vs Tasks\]\]
- [[Milestone]]
+-   \[\[Dependencies\]\]
- [[Dependencies]]
+-   \[\[Estimation and Forecasting\]\]
- [[Capacity]]
+-   \[\[Prioritization\]\]
- [[Risk]]
+-   \[\[Capacity and WIP\]\]
- [[Project Health]]
+-   \[\[Risk Management\]\]
- [[Portfolio Management]]
+-   \[\[Project Health\]\]
 -   \[\[Status Reporting\]\]
 -   \[\[Meetings and Follow-up\]\]
 -   \[\[Ownership and Delegation\]\]
 -   \[\[Portfolio Management\]\]
 -   \[\[Closing Projects\]\]
@@ -1,103 +1,97 @@
 # Capacity and WIP
-Duration: 30–40 minutes
+
 Duration: 30--40 minutes
 ## Definition
-Plan around real team capacity, operational interruptions, and limits on concurrent work.
+Capacity is the amount of work a person or team can realistically take
-
+on. Work in Progress (WIP) is work started but not finished. A WIP limit
-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+deliberately restricts concurrent work.
 ## 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.
+**Starting more does not mean finishing more.**
 ## How It Works
-We will examine this concept through four levels:
+A 35-hour work week is not 35 project hours:
 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
+35 hours
-Project Owner → drives milestones and delivery
+├── 10h operations/tickets
-Manager → manages projects, priorities, risks and escalation
+├── 5h meetings/admin
-Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs
+├── 5h support/incidents
 └── 15h project capacity
 ```
 The exact split varies. The principle is that operational work consumes
 real capacity.
 Capacity also depends on specialties. You can have available developer
 capacity while QA is overloaded, making QA the bottleneck.
 Too much WIP creates context switching:
 > Start → interrupt → switch → wait → restart
 Reducing WIP can increase throughput even though fewer projects appear
 active.
 ### Example
 Two integrators each have four active projects plus tickets. After a
 month, all eight projects moved slightly but none finished. Limiting
 major active projects can produce fewer "In Progress" rows but more
 completed outcomes.
 ### My Company / Real-World Context
 Your team handles projects, Product work, Jira tickets, synchronization
 incidents, QA, Data, SEO/WCAG, and meetings. Your portfolio should
 eventually show what is truly active and what is intentionally queued.
 Operational interruptions that happen every week are not exceptional.
 Planning should account for them.
 ### CTO Perspective
 If leadership wants ten initiatives but the organization can reliably
 execute four, expose the constraint. Choices include doing fewer things,
 reducing scope, extending timelines, adding capacity, reducing
 operational load, improving automation, or accepting risk.
 ### Questions to Ask
- What information do I need to make a management decision?
+-   How much project capacity do we actually have?
- What should the project owner be responsible for maintaining?
+-   What percentage is regularly consumed by operations?
- What requires my intervention?
+-   How many projects are active per owner?
- What can be standardized across every project?
+-   Which role is the bottleneck?
- Is the process helping delivery, or merely creating administration?
+-   What should remain queued?
 -   What does a new project displace?
-## Meeting Scenario
+### Key Takeaways
-**Situation:**
+-   Theoretical hours are not project capacity.
 -   Operations consume capacity and should be planned for.
 -   Too much WIP creates context switching and unfinished work.
 -   WIP limits help teams finish before starting more.
 -   Bottlenecks may be role-specific.
 -   A healthy portfolio contains queued work, not only active work.
-A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome.
+## How It Fits Into the Bigger Picture
-**Possible response:**
+This lesson builds on \[\[Projects vs Operations\]\], \[\[Outcomes and
-
+Definition of Done\]\], \[\[Scope and Scope Creep\]\], and
-> 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.
+\[\[Milestones vs Tasks\]\]. It prepares the project system to become
-
+more predictable and scalable.
 ## 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]]
+-   \[\[Milestones vs Tasks\]\]
- [[Project Outcome]]
+-   \[\[Dependencies\]\]
- [[Definition of Done]]
+-   \[\[Estimation and Forecasting\]\]
- [[Scope]]
+-   \[\[Prioritization\]\]
- [[Milestone]]
+-   \[[Capacity and WIP](#capacity-and-wip)\]
- [[Dependencies]]
+-   \[\[Risk Management\]\]
- [[Capacity]]
+-   \[\[Project Health\]\]
- [[Risk]]
+-   \[\[Portfolio Management\]\]
 - [[Project Health]]
 - [[Portfolio Management]]
@@ -1,103 +1,121 @@
-# Closing Projects
+
-Duration: 30–40 minutes
+Duration: 30--40 minutes
 ## Definition
-Formally accept outcomes, hand work to operations, document lessons, and close projects.
+**Project closure** confirms that the agreed outcome and Definition of
 Done are satisfied, ongoing responsibilities are handed off, and the
 project can leave the active portfolio.
-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+A project is not closed simply because development stopped.
 ## 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.
+> **Done → accepted → handed off → closed.**
 ## How It Works
-We will examine this concept through four levels:
+Before closure verify:
-1. What the concept means.
+### Outcome / DoD
-2. How a project owner should use it.
+
-3. How you should review or challenge it as the manager.
+-   Was the intended outcome achieved?
-4. How it should eventually appear in your project-management system.
+-   Are mandatory DoD criteria satisfied?
 -   Has the right stakeholder accepted it?
 ### Handoff
 -   Who owns it operationally?
 -   Is monitoring in place?
 -   Is documentation sufficient?
 -   Are support responsibilities clear?
 -   Are access/credentials transferred where relevant?
 ### Remaining work
 Separate:
 -   Required for DoD
 -   Defect that blocks acceptance
 -   Enhancement/backlog item
 -   Future Phase 2
 Not every improvement needs to keep the project open.
 ### Lessons learned
 Keep it lightweight:
 -   What worked?
 -   What caused delay?
 -   What should we repeat?
 -   What should change next time?
 ## 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.
+QA automation reaches its agreed DoD. Product asks for five more
-
+automated scenarios. If they were not required for the outcome, put them
-The objective is to move from theory to a repeatable management practice.
+in backlog or Phase 2 and close the original project.
 ## How It Fits Into the Bigger Picture
-The course builds progressively:
+Lesson 1 established that projects are temporary. Lesson 2 created
-
+Definition of Done. Closure is where those ideas are enforced and the
- Project vs operations establishes what kind of work we are managing.
+project transitions to operations where necessary.
 - 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.
+Monitoring systems, analytics platforms, synchronization processes, QA
 automation, and website capabilities all create ongoing
 responsibilities.
-The lesson should therefore be applied to an environment where:
+Every successful project can therefore add operational load. That new
-
+load affects future project capacity and should be visible.
 - 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.
+A project that launches without an operational owner, monitoring,
 documentation, or support model may simply transfer risk into the
 organization.
-The expected progression is:
+Closure is not paperwork. It confirms the organization can safely live
-
+with what was delivered.
 ```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?
+-   Has the outcome been achieved?
- What should the project owner be responsible for maintaining?
+-   Does the DoD pass?
- What requires my intervention?
+-   Who accepts it?
- What can be standardized across every project?
+-   Who owns it after closure?
- Is the process helping delivery, or merely creating administration?
+-   What operational load does it create?
 -   Are remaining items blockers or enhancements?
 -   What did we learn?
 -   Can it leave the active portfolio?
 ## Meeting Scenario
-**Situation:**
+**Situation:** Development and QA are complete, but nice-to-have
-
+improvements keep the project open indefinitely.
 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.
+> Let's compare the remaining items to the agreed Definition of Done. If
 > the outcome is achieved and these are enhancements, we'll close the
 > project and move them into backlog or Phase 2.
 ## Key Takeaways
- The purpose of project management is predictable delivery, not documentation for its own sake.
+-   Closure validates outcome and DoD.
- Project owners should own increasingly more of the planning and maintenance.
+-   Development completion alone does not close a project.
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
+-   Operational ownership must be explicit.
- Every concept learned should eventually contribute to one lightweight common project template.
+-   Enhancements do not necessarily block closure.
- The final system should make exceptions and problems visible without requiring you to inspect every task.
+-   Closure removes unnecessary project overhead.
 -   Every completed project may create new operational load.
 ## Related Concepts
 -   [[Projects vs Operations]]
- [[Project Outcome]]
+-   [[Outcomes and Definition of Done]]
- [[Definition of Done]]
+-   [[Scope and Scope Creep]]
- [[Scope]]
+-   [[Capacity and WIP]]
 - [[Milestone]]
 - [[Dependencies]]
 - [[Capacity]]
 - [[Risk]]
 - [[Project Health]]
 -   [[Portfolio Management]]
@@ -1,100 +1,106 @@
-Duration: 30–40 minutes
+Duration: 30--40 minutes
 ## Definition
-Identify work, people, teams, vendors, and decisions that can block delivery.
+A dependency is something a project needs but does not fully control. It
-
+may be another task, person, team, vendor, environment, approval,
-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+decision, data source, or access requirement. A blocker is a dependency
 that is currently preventing progress.
 ## Simple Mental Model
-The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage.
+**What must happen outside this work before we can reach the next
 milestone?**
 ## How It Works
-We will examine this concept through four levels:
+Project owners should identify dependencies early, record who owns them
 and when they are needed, follow up before they become blockers, and
 escalate when authority or priority is required.
-1. What the concept means.
+### Dependency types
 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
+-   Internal: another task or contributor inside the project
 -   Cross-team: Product, DevOps, Security, IT, Finance, etc.
 -   External: vendor, partner, contractor
 -   Decision: approval or choice required before work can proceed
-The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security.
+A dependency is not automatically a risk. "DevOps must create the
 environment" is a dependency. "DevOps may not have capacity by August
 15" is a risk.
-The objective is to move from theory to a repeatable management practice.
+### Example
-## How It Fits Into the Bigger Picture
+For an analytics implementation:
-The course builds progressively:
+  -----------------------------------------------------------------------
  Dependency        Owner             Needed by         Impact if late
  ----------------- ----------------- ----------------- -----------------
  Production        DevOps            Aug 15            QA cannot start
  environment                                           
- Project vs operations establishes what kind of work we are managing.
+  Security review   Security          Aug 20            Production
- Outcomes and Definition of Done establish what success means.
+                                                        blocked
 - 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
+  Tracking          Product/Data      Aug 5             Implementation
  requirements                                          unclear
  -----------------------------------------------------------------------
-Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security.
+In your environment this matters because project owners frequently
 depend on Product, DevOps, Security, vendors, QA, and other departments.
 The owner may not control those teams, but still owns making the
 dependency visible and following it.
-The lesson should therefore be applied to an environment where:
+### CTO Perspective
- Project owners are usually members of your own team rather than dedicated PMs.
+You should not personally chase every dependency. The owner manages
- Operational work regularly interrupts project work.
+normal follow-up. You intervene when priorities conflict, a committed
- Product and IT are important cross-functional partners.
+milestone is threatened, the owner lacks authority, or the same
- You need portfolio-level visibility without personally maintaining every task.
+bottleneck repeatedly affects projects.
 - 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 does the next milestone depend on?
- What should the project owner be responsible for maintaining?
+-   Who owns it?
- What requires my intervention?
+-   When is it needed?
- What can be standardized across every project?
+-   Has the other team actually committed?
- Is the process helping delivery, or merely creating administration?
+-   What happens if it is late?
 -   When should this be escalated?
-## Meeting Scenario
+### Meeting Scenario
-**Situation:**
+**Situation:** The owner says Friday's milestone will slip because
-
+DevOps has not created the environment.
 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.
+> When did we identify the dependency, what date did DevOps commit to,
 > and when did we know it was at risk? If you've already followed up and
 > the milestone is threatened, I'll help escalate it.
-## Key Takeaways
+### Key Takeaways
- The purpose of project management is predictable delivery, not documentation for its own sake.
+-   Dependencies are things the project needs but does not fully
- Project owners should own increasingly more of the planning and maintenance.
+    control.
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
+-   Blockers are dependencies actively preventing progress.
- Every concept learned should eventually contribute to one lightweight common project template.
+-   Identify dependencies from milestones before they are needed.
- The final system should make exceptions and problems visible without requiring you to inspect every task.
+-   Project owners manage routine follow-up.
 -   Managers handle cross-team priority and authority escalation.
 -   Repeated dependency failures may reveal an organizational
    bottleneck.
 ## How It Fits Into the Bigger Picture
 This lesson builds on [[Projects vs Operations]], [[Outcomes and
 Definition of Done]], [[Scope and Scope Creep]], and
 [[Milestones vs Tasks]]. It prepares the project system to become
 more predictable and scalable.
 ## Related Concepts
 - [[Projects vs Operations]]
 - [[Outcomes and Definition of Done]]
 - [[Scope and Scope Creep]]
 -   [[Milestones vs Tasks]]
- [[Dependencies]]
+-   [[Estimation and Forecasting]]
 -   [[Prioritization]]
 -   [[Capacity and WIP]]
 -   [[Risk Management]]
 -   [[Project Health]]
@@ -1,102 +1,105 @@
-Duration: 30–40 minutes
+Duration: 30--40 minutes
 ## Definition
-Build realistic estimates and distinguish estimates, targets, and commitments.
+Estimation predicts the effort or time required for work. Forecasting
-
+combines estimates with capacity, dependencies, uncertainty, and current
-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+progress to predict delivery. Keep **estimate**, **target**, and
 **commitment** separate.
 ## 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.
+**Estimate the work. Forecast the date. Agree on the commitment.**
 ## How It Works
-We will examine this concept through four levels:
+A target such as "leadership wants September 1" is not automatically an
 estimate or commitment.
-1. What the concept means.
+Estimate milestone by milestone after outcome, scope, and major
-2. How a project owner should use it.
+dependencies are understood. Then account for real constraints.
 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
+Requirements      1 week
-Project Owner → drives milestones and delivery
+Implementation    3 weeks
-Manager → manages projects, priorities, risks and escalation
+QA                1 week
-Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs
+Deployment        1 week
 ```
 This does not automatically equal six calendar weeks. People have
 operational work, dependencies create waiting time, work may overlap,
 and uncertainty exists.
 Use ranges when uncertainty is high. "6--9 weeks" can be more
 responsible early on than false precision.
 State assumptions:
 > Six weeks assuming DevOps delivers the environment by Aug 10 and the
 > owner has roughly 50% project capacity.
 If assumptions change, the forecast should change.
 ### Example
 An owner proposes eight weeks:
 -   3 weeks implementation
 -   1 week QA
 -   1 week deployment
 -   1 week Product validation
 -   2 weeks availability/operational interruption
 Do not simply change eight to five. Challenge the assumptions. Can work
 overlap? Is the operational allowance supported by history? Can a
 dependency start earlier?
 ### My Company / Real-World Context
 Your projects are interrupted by tickets and production issues, so
 project effort and calendar duration differ. An 80-hour project can take
 many calendar weeks if only 10--15 hours per week are realistically
 available.
 ### CTO Perspective
 Aggressive dates do not create capacity. If a target must move earlier,
 identify the trade-off: scope, priority, capacity, sequencing,
 dependency acceleration, or increased risk.
 ### Questions to Ask
- What information do I need to make a management decision?
+-   What is the estimate based on?
- What should the project owner be responsible for maintaining?
+-   Which milestone has the most uncertainty?
- What requires my intervention?
+-   What assumptions are we making?
- What can be standardized across every project?
+-   What capacity is actually available?
- Is the process helping delivery, or merely creating administration?
+-   What is the requested target?
 -   What can the team reasonably commit to?
 -   What would need to change to deliver sooner?
-## Meeting Scenario
+### Key Takeaways
-**Situation:**
+-   Estimate, target, and commitment are different.
 -   Forecasts combine effort with real constraints.
 -   Ranges are useful when uncertainty is real.
 -   Important assumptions should be explicit.
 -   Challenge estimates by challenging assumptions, not by arbitrarily
    shortening them.
 -   Faster delivery normally requires a trade-off.
-A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome.
+## How It Fits Into the Bigger Picture
-**Possible response:**
+This lesson builds on [[Projects vs Operations]], [[Outcomes and
-
+Definition of Done]], [[Scope and Scope Creep]], and
-> 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.
+[[Milestones vs Tasks]]. It prepares the project system to become
-
+more predictable and scalable.
 ## 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]]
+-   [[Milestones vs Tasks]]
 - [[Project Outcome]]
 - [[Definition of Done]]
 - [[Scope]]
 - [[Milestone]]
 -   [[Dependencies]]
- [[Capacity]]
+-   [[Prioritization]]
- [[Risk]]
+-   [[Capacity and WIP]]
 -   [[Risk Management]]
 -   [[Project Health]]
 -   [[Portfolio Management]]
@@ -1,103 +1,104 @@
 # Meetings and Follow-up
-Duration: 30–40 minutes
+
 Duration: 30--40 minutes
 ## Definition
-Run project meetings around decisions, blockers, ownership, and next actions.
+A project meeting is a coordination mechanism for decisions, blockers,
 alignment, and delivery. A meeting is not progress by itself.
-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+**Follow-up** converts discussion into owned actions and decisions.
 ## 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.
+> **A useful project meeting changes something.**
 At the end you should know what was decided, who owns what, by when,
 what is blocked, and what needs escalation.
 ## How It Works
-We will examine this concept through four levels:
+Do not automatically create a recurring meeting for every project.
-1. What the concept means.
+A useful review agenda:
-2. How a project owner should use it.
+
-3. How you should review or challenge it as the manager.
+1.  Outcome / health
-4. How it should eventually appear in your project-management system.
+2.  Last and next milestone
 3.  Risks/blockers
 4.  Scope changes
 5.  Decisions required
 6.  Actions, owners, dates
 Distinguish:
 **Decision:** We will use Option B.
 **Action:** Alex updates the architecture by Friday.
 Avoid "team to investigate." Give actions one owner and a date.
 Use asynchronous status for routine information. Use meetings when
 synchronous coordination adds value.
 ## 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.
+A weekly 60-minute meeting with eight people mostly consists of everyone
-
+describing what they did. Replace the reporting portion asynchronously
-The objective is to move from theory to a repeatable management practice.
+and use synchronous time for two blockers and one scope decision.
 ## How It Fits Into the Bigger Picture
-The course builds progressively:
+Status reporting communicates project state. Meetings resolve what
-
+cannot efficiently be resolved asynchronously. \[\[Ownership and
- Project vs operations establishes what kind of work we are managing.
+Delegation\]\] determines who follows through afterward.
 - 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.
+Cross-functional work with Product, DevOps, Security, IT, and vendors
-
+can create meeting overload. Your project owner should drive normal
-The lesson should therefore be applied to an environment where:
+project follow-up. You join when your authority, escalation, or judgment
-
+is required.
 - 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.
+If every project requires you in every meeting, **you are the system**.
-
+A scalable leader designs ownership and information flow so their
-The expected progression is:
+presence is needed only where it adds value.
 ```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?
+-   Does this require a meeting?
- What should the project owner be responsible for maintaining?
+-   What decision must be made?
- What requires my intervention?
+-   Who actually needs to attend?
- What can be standardized across every project?
+-   What is blocked?
- Is the process helping delivery, or merely creating administration?
+-   Who owns each action?
 -   By when?
 -   Can the owner follow this without me?
 ## Meeting Scenario
-**Situation:**
+**Situation:** An owner includes you in a weekly execution meeting where
-
+most discussion is detailed implementation.
 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.
+> I don't need to be in the detailed execution meeting unless there's a
 > decision, priority conflict, or escalation requiring me. Keep the
 > project status current and bring me in when one of those conditions
 > appears.
 ## Key Takeaways
- The purpose of project management is predictable delivery, not documentation for its own sake.
+-   Meetings are tools, not evidence of progress.
- Project owners should own increasingly more of the planning and maintenance.
+-   Use synchronous time for decisions, blockers, and coordination.
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
+-   Actions need owners and dates.
- Every concept learned should eventually contribute to one lightweight common project template.
+-   Capture decisions separately.
- The final system should make exceptions and problems visible without requiring you to inspect every task.
+-   Prefer asynchronous status where possible.
 -   Project owners should drive normal follow-up.
 ## Related Concepts
- [[Projects vs Operations]]
+-   \[\[Status Reporting\]\]
- [[Project Outcome]]
+-   \[\[Ownership and Delegation\]\]
- [[Definition of Done]]
+-   \[\[Decision Log\]\]
- [[Scope]]
+-   \[\[Project Health\]\]
 - [[Milestone]]
 - [[Dependencies]]
 - [[Capacity]]
 - [[Risk]]
 - [[Project Health]]
 - [[Portfolio Management]]
@@ -1,103 +1,134 @@
 # Ownership and Delegation
-Duration: 30–40 minutes
+
 Duration: 30--40 minutes
 ## Definition
-Make project ownership clear and develop team members who can drive projects.
+**Project ownership** means one person is accountable for driving a
 project toward its agreed outcome. The owner does not need to perform
 every task.
-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+**Delegation** transfers responsibility and appropriate authority while
 keeping enough management visibility to ensure the outcome.
 ## 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.
+> **One project, one clearly accountable owner.**
 The owner manages the project. You manage the owner, priorities,
 escalation, and portfolio.
 ## How It Works
-We will examine this concept through four levels:
+A project owner should increasingly:
-1. What the concept means.
+-   Draft the project brief
-2. How a project owner should use it.
+-   Clarify outcome and DoD
-3. How you should review or challenge it as the manager.
+-   Propose scope and milestones
-4. How it should eventually appear in your project-management system.
+-   Identify dependencies and risks
 -   Coordinate contributors
 -   Maintain status
 -   Surface scope changes
 -   Escalate blockers
 -   Drive closure
 Your role:
 -   Approve and prioritize
 -   Challenge the plan
 -   Confirm commitments
 -   Coach
 -   Resolve priority/authority conflicts
 -   Escalate organizational blockers
 -   Review outcomes
 Delegation can increase progressively:
 1.  Research and report
 2.  Recommend a plan
 3.  Act after approval
 4.  Act and inform
 5.  Own the outcome within agreed boundaries
 Accountability must come with enough authority to coordinate and
 escalate.
 ## 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.
+Instead of writing the Umami plan yourself:
-The objective is to move from theory to a repeatable management practice.
+> Draft the outcome, DoD, scope, milestones, dependencies, risks, and
 > proposed forecast. We'll review it together Friday.
 The owner proposes eight weeks. You challenge assumptions and agree on a
 commitment. They maintain the project afterward.
 ## How It Fits Into the Bigger Picture
-The course builds progressively:
+Everything learned so far becomes information the project owner manages.
 This is the transition from:
- Project vs operations establishes what kind of work we are managing.
+> Amadou manages every project
- Outcomes and Definition of Done establish what success means.
+
- Scope establishes the project's boundaries.
+to:
- Milestones establish meaningful progress.
+
- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable.
+> Amadou manages a system in which people can own projects.
 - 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.
+You do not have a PMO assigning PMs to your work. Integrators, analysts,
 QA, or other team members can own projects depending on capability and
 subject matter.
-The lesson should therefore be applied to an environment where:
+Project ownership also develops employees beyond ticket execution.
 - 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.
+Broader technology leadership requires an organization that can operate
 without you personally coordinating everything.
-The expected progression is:
+The goal is:
-```text
+> I know the portfolio and intervene where needed.
-Contributor → manages tasks
+
-Project Owner → drives milestones and delivery
+not:
-Manager → manages projects, priorities, risks and escalation
+
-Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs
+> Nothing moves unless I chase it.
 ```
 ### Questions to Ask
- What information do I need to make a management decision?
+-   Who is the single owner?
- What should the project owner be responsible for maintaining?
+-   What can they decide without me?
- What requires my intervention?
+-   What must come back to me?
- What can be standardized across every project?
+-   Are they maintaining the project or am I?
- Is the process helping delivery, or merely creating administration?
+-   Are they escalating early?
 -   Am I coaching or taking the project back?
 -   Does accountability match authority?
 ## Meeting Scenario
-**Situation:**
+**Situation:** An owner finds a Product request that changes scope and
-
+immediately asks you what to do.
 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.
+> You've identified the scope change correctly. Before I decide, tell me
 > the impact on the milestone and what options you recommend. Bring me
 > the trade-off, not only the problem.
 ## Key Takeaways
- The purpose of project management is predictable delivery, not documentation for its own sake.
+-   Every project needs one clearly accountable owner.
- Project owners should own increasingly more of the planning and maintenance.
+-   Owners drive outcomes; they do not perform every task.
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
+-   Owners should draft and maintain the project brief.
- Every concept learned should eventually contribute to one lightweight common project template.
+-   Managers validate, challenge, coach, prioritize, and escalate.
- The final system should make exceptions and problems visible without requiring you to inspect every task.
+-   Delegation increases with capability.
 -   Accountability must match authority.
 -   Developing owners makes the system scalable.
 ## Related Concepts
- [[Projects vs Operations]]
+-   \[\[Portfolio Management\]\]
- [[Project Outcome]]
+-   \[\[Meetings and Follow-up\]\]
- [[Definition of Done]]
+-   \[\[Status Reporting\]\]
- [[Scope]]
+-   \[\[Project Health\]\]
 - [[Milestone]]
 - [[Dependencies]]
 - [[Capacity]]
 - [[Risk]]
 - [[Project Health]]
 - [[Portfolio Management]]
@@ -1,103 +1,136 @@
 # Portfolio Management
-Duration: 30–40 minutes
+
 Duration: 30--40 minutes
 ## Definition
-Manage the collection of projects as a system rather than independently.
+**Portfolio management** manages multiple projects as a collection
 competing for the same organizational resources.
-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+Project management asks:
 > How do we deliver this project?
 Portfolio management asks:
 > Which projects should we be doing, in what order, and with what
 > capacity?
 ## 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.
+> **Projects compete with each other. The portfolio makes the trade-offs
 > visible.**
 ## How It Works
-We will examine this concept through four levels:
+A portfolio should answer:
-1. What the concept means.
+-   What is active?
-2. How a project owner should use it.
+-   What is queued?
-3. How you should review or challenge it as the manager.
+-   What is on hold?
-4. How it should eventually appear in your project-management system.
+-   What is the priority?
 -   Who owns it?
 -   What is the health?
 -   What is the next milestone?
 -   Where is capacity constrained?
 Useful portfolio states:
 -   Proposed
 -   Approved / queued
 -   Active
 -   On hold
 -   Closing
 -   Closed
 Approved does not need to mean active.
 A portfolio review asks:
 1.  Which projects changed health?
 2.  Which milestones slipped?
 3.  Which need intervention?
 4.  What new work is proposed?
 5.  Do we have capacity?
 6.  What should pause or remain queued?
 7.  Are priorities still aligned?
 The portfolio is not a giant task board.
 ## 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.
+Your board has 16 projects and 12 appear active. Capacity review shows
 the team can reliably support six major initiatives while handling
 operations.
-The objective is to move from theory to a repeatable management practice.
+The portfolio decision is not "work faster." It is to choose the active
 six, queue the others, and make the trade-off explicit.
 ## How It Fits Into the Bigger Picture
-The course builds progressively:
+\[\[Prioritization\]\] decides relative importance. \[\[Capacity and
-
+WIP\]\] determines how much can be active. \[\[Project Health\]\]
- Project vs operations establishes what kind of work we are managing.
+identifies where intervention is needed. Portfolio management combines
- Outcomes and Definition of Done establish what success means.
+them.
 - 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.
+Your Monday board is already attempting to be a portfolio. It has
 projects, priority, owner, status, and timelines.
-The lesson should therefore be applied to an environment where:
+The eventual goal is for it to answer:
- Project owners are usually members of your own team rather than dedicated PMs.
+> **What needs my attention?**
- Operational work regularly interrupts project work.
+
- Product and IT are important cross-functional partners.
+rather than merely:
- 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.
+> What projects exist?
 ## CTO Perspective
-The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes.
+Portfolio management is a major shift from execution to organizational
 leadership. Every project approval consumes people, money, and attention
 that cannot simultaneously be used elsewhere.
-The expected progression is:
+> **Every project approval is a resource-allocation decision.**
 ```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?
+-   Why are we doing this?
- What should the project owner be responsible for maintaining?
+-   What is its priority relative to others?
- What requires my intervention?
+-   Do we have capacity to start?
- What can be standardized across every project?
+-   What will it displace?
- Is the process helping delivery, or merely creating administration?
+-   How many projects are active?
 -   Which are Yellow/Red?
 -   Where are bottlenecks?
 -   Which projects should pause or stop?
 -   What should start next?
 ## Meeting Scenario
-**Situation:**
+**Situation:** Leadership approves another initiative and asks when your
-
+team can begin.
 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.
+> I'll add it to the portfolio and assess it against current priorities
 > and capacity. If it must start immediately, I'll show which existing
 > commitment would need to move so we can make that trade-off
 > explicitly.
 ## Key Takeaways
- The purpose of project management is predictable delivery, not documentation for its own sake.
+-   Portfolio management manages projects as a competing collection.
- Project owners should own increasingly more of the planning and maintenance.
+-   Approved does not mean active.
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
+-   Queued and on-hold states are healthy.
- Every concept learned should eventually contribute to one lightweight common project template.
+-   Portfolio views focus on management information, not task detail.
- The final system should make exceptions and problems visible without requiring you to inspect every task.
+-   Priority, capacity, WIP, and health come together here.
 -   Starting new work should expose what it displaces.
 ## Related Concepts
- [[Projects vs Operations]]
+-   \[\[Prioritization\]\]
- [[Project Outcome]]
+-   \[\[Capacity and WIP\]\]
- [[Definition of Done]]
+-   \[\[Project Health\]\]
- [[Scope]]
+-   \[\[Status Reporting\]\]
- [[Milestone]]
+-   \[\[Ownership and Delegation\]\]
 - [[Dependencies]]
 - [[Capacity]]
 - [[Risk]]
 - [[Project Health]]
 - [[Portfolio Management]]
@@ -1,103 +1,98 @@
 # Prioritization
-Duration: 30–40 minutes
+
 Duration: 30--40 minutes
 ## Definition
-Decide what should be worked on now when everything appears important.
+Prioritization is the deliberate decision about which work receives
-
+scarce capacity first. A priority is meaningful only if it changes what
-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+the team does.
 ## 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.
+**Priority means what wins when two important things compete for the
 same capacity.**
 ## How It Works
-We will examine this concept through four levels:
+If ten projects are all High, you have not prioritized them.
-1. What the concept means.
+Useful factors include business value, urgency, risk reduction, fixed
-2. How a project owner should use it.
+deadlines, strategic alignment, dependencies, effort, and cost of delay.
 3. How you should review or challenge it as the manager.
 4. How it should eventually appear in your project-management system.
-## Example
+Priority is relative:
 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
+1. Production incident
-Project Owner → drives milestones and delivery
+2. Supabase migration
-Manager → manages projects, priorities, risks and escalation
+3. Umami
-Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs
+4. QA automation
 5. RAG POC
 ```
 A new top priority should force the question:
 > What is no longer the top priority?
 ### Strategic vs Urgent
 Urgent work can consume all capacity while important strategic work
 never progresses. Some capacity may need protection from recurring
 urgency.
 ### Example
 Product requests an urgent website enhancement while an integrator is
 committed to an Umami milestone. Do not silently add it. Decide whether
 it outranks Umami and, if so, record which milestone moves.
 ### My Company / Real-World Context
 Your team receives work from your roadmap, Product, operational
 incidents, Jira requests, IT/security needs, vendors, and leadership.
 Without explicit prioritization, the loudest request can become the real
 priority.
 ### CTO Perspective
 The leadership question is not merely "Is this valuable?" Most portfolio
 items are valuable. Ask:
 > Is this more valuable **now** than the work it will displace?
 ### Questions to Ask
- What information do I need to make a management decision?
+-   What happens if we do not do this now?
- What should the project owner be responsible for maintaining?
+-   Is there a fixed deadline?
- What requires my intervention?
+-   What business outcome does it support?
- What can be standardized across every project?
+-   What does it unblock?
- Is the process helping delivery, or merely creating administration?
+-   What will move if this becomes priority?
 -   Who can change the priority?
-## Meeting Scenario
+### Key Takeaways
-**Situation:**
+-   Prioritization allocates scarce capacity.
 -   Everything cannot be High.
 -   Priority must resolve conflicts between work.
 -   New urgent work should expose what it displaces.
 -   Constant reprioritization damages predictability.
 -   Managers should resolve cross-project priority conflicts rather than
    leaving contributors to choose.
-A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome.
+## How It Fits Into the Bigger Picture
-**Possible response:**
+This lesson builds on \[\[Projects vs Operations\]\], \[\[Outcomes and
-
+Definition of Done\]\], \[\[Scope and Scope Creep\]\], and
-> 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.
+\[\[Milestones vs Tasks\]\]. It prepares the project system to become
-
+more predictable and scalable.
 ## 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]]
+-   \[\[Milestones vs Tasks\]\]
- [[Project Outcome]]
+-   \[\[Dependencies\]\]
- [[Definition of Done]]
+-   \[\[Estimation and Forecasting\]\]
- [[Scope]]
+-   \[[Prioritization](#prioritization)\]
- [[Milestone]]
+-   \[\[Capacity and WIP\]\]
- [[Dependencies]]
+-   \[\[Risk Management\]\]
- [[Capacity]]
+-   \[\[Project Health\]\]
- [[Risk]]
+-   \[\[Portfolio Management\]\]
 - [[Project Health]]
 - [[Portfolio Management]]
@@ -1,103 +1,115 @@
 # Project Health
-Duration: 30–40 minutes
+
 Duration: 30--40 minutes
 ## Definition
-Use evidence to classify projects as healthy, at risk, or off track.
+**Project health** is a concise assessment of whether a project is
 likely to achieve its agreed outcome within its current commitments.
-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+A common model is:
 -   **Green:** on track; no material intervention required.
 -   **Yellow:** at risk; attention or corrective action is needed.
 -   **Red:** off track or blocked; significant intervention or decision
    is required.
 ## 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.
+> **Project health answers: Do I need to worry or intervene?**
 Green does not mean people are busy. It means the evidence supports
 confidence in delivery.
 ## How It Works
-We will examine this concept through four levels:
+Health should consider:
-1. What the concept means.
+-   Next milestone and target
-2. How a project owner should use it.
+-   Current forecast
-3. How you should review or challenge it as the manager.
+-   Scope stability
-4. How it should eventually appear in your project-management system.
+-   Dependencies
 -   Risks/issues
 -   Capacity
 -   Quality/acceptance
 -   Decisions required
-## Example
+Yellow should be an early-warning state, not a punishment.
-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.
+Example:
-The objective is to move from theory to a repeatable management practice.
+Umami's production validation is due Aug 20. Development is complete,
 but DevOps now expects the environment Aug 18 and QA needs four days.
 The deadline has not passed, but the project is already **Yellow**.
 Do not wait until Aug 21 to discover the problem.
 ## How It Fits Into the Bigger Picture
-The course builds progressively:
+Milestones provide checkpoints. Dependencies and risks explain threats.
-
+Forecasting predicts delivery. Health compresses those signals into a
- Project vs operations establishes what kind of work we are managing.
+portfolio-level indicator.
 - 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.
+Your Monday board currently shows execution status, but your management
 need is closer to:
-The lesson should therefore be applied to an environment where:
+``` text
 Umami              Yellow
 Supabase            Green
 Mogador             Red
 QA Automation       Green
 Data Governance     Yellow
 ```
- Project owners are usually members of your own team rather than dedicated PMs.
+Then you focus your attention on Yellow and Red rather than opening
- Operational work regularly interrupts project work.
+every project.
 - 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.
+Health indicators enable **management by exception**. But the colors
 must be trustworthy.
-The expected progression is:
+If owners keep projects Green until failure is undeniable, the system is
-
+useless. Make early Yellow reporting useful rather than treating it as
-```text
+failure.
 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 is the next milestone?
- What should the project owner be responsible for maintaining?
+-   Is the forecast still credible?
- What requires my intervention?
+-   What is the biggest risk?
- What can be standardized across every project?
+-   Is scope stable?
- Is the process helping delivery, or merely creating administration?
+-   Are dependencies committed?
 -   What specifically would return Yellow to Green?
 -   Does this need my intervention?
 ## Meeting Scenario
-**Situation:**
+**Situation:** A project owner reports Green because no deadline has
-
+been missed, but a critical vendor deliverable has no confirmed date.
 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.
+> I would mark this Yellow. Health should reflect whether we're likely
 > to hit the commitment, not only whether we've already missed it. What
 > action will give us confidence in the vendor dependency?
 ## Key Takeaways
- The purpose of project management is predictable delivery, not documentation for its own sake.
+-   Health is forward-looking.
- Project owners should own increasingly more of the planning and maintenance.
+-   Green/Yellow/Red need shared definitions.
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
+-   Yellow is an early-warning state.
- Every concept learned should eventually contribute to one lightweight common project template.
+-   Percent complete is not project health.
- The final system should make exceptions and problems visible without requiring you to inspect every task.
+-   Health should reflect milestones, risks, dependencies, scope, and
    forecast.
 -   Reliable health enables management by exception.
 ## Related Concepts
- [[Projects vs Operations]]
+-   \[\[Milestones vs Tasks\]\]
- [[Project Outcome]]
+-   \[\[Risk Management\]\]
- [[Definition of Done]]
+-   \[\[Dependencies\]\]
- [[Scope]]
+-   \[\[Status Reporting\]\]
- [[Milestone]]
+-   \[\[Portfolio Management\]\]
 - [[Dependencies]]
 - [[Capacity]]
 - [[Risk]]
 - [[Project Health]]
 - [[Portfolio Management]]
@@ -1,103 +1,110 @@
 # Risk Management
-Duration: 30–40 minutes
+
 Duration: 30--40 minutes
 ## Definition
-Identify, assess, mitigate, and monitor risks before they become project problems.
+A **risk** is an uncertain event or condition that could affect the
-
+project's outcome, schedule, scope, quality, cost, or operations. An
-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+**issue** is a problem that is already happening.
 ## 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.
+> **Risk = might happen. Issue = is happening.**
 Good project management tries to identify important uncertainty before
 it becomes a surprise.
 ## How It Works
-We will examine this concept through four levels:
+Use a lightweight four-step process:
-1. What the concept means.
+1.  **Identify** what could prevent the outcome or next milestone.
-2. How a project owner should use it.
+2.  **Assess** probability and impact.
-3. How you should review or challenge it as the manager.
+3.  **Respond** by avoiding, mitigating, transferring/sharing, or
-4. How it should eventually appear in your project-management system.
+    accepting the risk.
 4.  **Monitor** the important risks as the project changes.
 You do not need fake numerical precision. Low / Medium / High is often
 enough.
 Example:
  --------------------------------------------------------------------------
  Risk           Probability    Impact         Response       Owner
  -------------- -------------- -------------- -------------- --------------
  DevOps         Medium         High           Confirm        Project owner
  unavailable                                  commitment     
  before QA                                    early          
  --------------------------------------------------------------------------
 A dependency is something you know the project needs. A risk is
 uncertainty around what might happen.
 ## 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.
+Your project is on schedule, but Security has not reviewed an
-
+architecture required for production. The deadline has not slipped yet,
-The objective is to move from theory to a repeatable management practice.
+but the unresolved review is a material risk. The project may already
 deserve Yellow health.
 ## How It Fits Into the Bigger Picture
-The course builds progressively:
+Dependencies tell you what the project needs. Estimation exposes
-
+assumptions. Risk management asks what could make those assumptions
- Project vs operations establishes what kind of work we are managing.
+fail. \[\[Project Health\]\] then reflects important risks before
- Outcomes and Definition of Done establish what success means.
+deadlines are actually missed.
 - 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.
+Likely project risks in your environment include vendor delivery, DevOps
 availability, Security approval, Product requirement changes,
 operational interruptions, QA availability, data quality, and key-person
 dependencies.
-The lesson should therefore be applied to an environment where:
+Focus on the few risks capable of materially changing delivery rather
-
+than maintaining a huge register nobody reads.
 - 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.
+A project should not remain Green merely because nothing bad has
-
+happened yet. Leadership status must be forward-looking.
 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 could prevent the next milestone?
- What should the project owner be responsible for maintaining?
+-   What assumptions are we relying on?
- What requires my intervention?
+-   Which risk has the highest impact?
- What can be standardized across every project?
+-   Who owns the response?
- Is the process helping delivery, or merely creating administration?
+-   What can we do now?
 -   What signal tells us the risk is becoming an issue?
 -   Does this risk change project health?
 ## Meeting Scenario
-**Situation:**
+**Situation:** Security has not reviewed a required architecture and
-
+production is approaching.
 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.
+> The milestone hasn't slipped yet, but the unresolved Security review
 > is now a material delivery risk. Let's get a committed review date and
 > escalate if that date threatens production.
 ## Key Takeaways
- The purpose of project management is predictable delivery, not documentation for its own sake.
+-   Risks are uncertain future events; issues are current problems.
- Project owners should own increasingly more of the planning and maintenance.
+-   Identify risks before they become blockers.
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
+-   Focus on material risks.
- Every concept learned should eventually contribute to one lightweight common project template.
+-   Assess probability and impact.
- The final system should make exceptions and problems visible without requiring you to inspect every task.
+-   Significant risks need an owner and response.
 -   Health should reflect major risks before a deadline is missed.
 ## Related Concepts
- [[Projects vs Operations]]
+-   \[\[Dependencies\]\]
- [[Project Outcome]]
+-   \[\[Project Health\]\]
- [[Definition of Done]]
+-   \[\[Estimation and Forecasting\]\]
- [[Scope]]
+-   \[\[Capacity and WIP\]\]
- [[Milestone]]
+-   \[\[RAID\]\]
 - [[Dependencies]]
 - [[Capacity]]
 - [[Risk]]
 - [[Project Health]]
 - [[Portfolio Management]]
@@ -1,103 +1,121 @@
 # Status Reporting
-Duration: 30–40 minutes
+
 Duration: 30--40 minutes
 ## Definition
-Communicate project status concisely to managers, executives, and stakeholders.
+**Status reporting** communicates the minimum information stakeholders
 need to understand current project state, expected delivery, major
 changes, and required decisions.
-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+A status report is not a diary of everything the team did.
 ## 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.
+> **Where are we? What is next? What threatens it? What do you need from
 > me?**
 ## How It Works
-We will examine this concept through four levels:
+A lightweight update can contain:
-1. What the concept means.
+``` text
-2. How a project owner should use it.
+Health:
-3. How you should review or challenge it as the manager.
+Outcome:
-4. How it should eventually appear in your project-management system.
+Next milestone:
 Target:
 What changed:
 Top risk/blocker:
 Decision/help needed:
 ```
 Different audiences need different depth:
 -   Project team: detailed execution
 -   You: milestones, risks, scope, forecast, blockers
 -   VP/executive: outcome, health, consequence, decision required
 Report meaningful changes, not noise.
 Weak:
 > Waiting on Security.
 Better:
 > Security review is outstanding. If not completed by Aug 15, production
 > validation will move by at least one week.
 ## 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.
+Weak update:
-The objective is to move from theory to a repeatable management practice.
+> We completed seven tickets and development is progressing.
 Better:
 > **Yellow.** Implementation is complete. Production validation is
 > targeted for Aug 20. The DevOps environment is four days late, leaving
 > insufficient QA time. We need delivery by Aug 16 to preserve the
 > target.
 ## How It Fits Into the Bigger Picture
-The course builds progressively:
+\[\[Project Health\]\] tells you whether attention is required. Status
-
+reporting explains why, what changed, and what action is needed.
 - 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.
+You communicate across Product, IT, vendors, and upper management.
 Translate technical events into delivery consequences.
-The lesson should therefore be applied to an environment where:
+Instead of "the sync API returns errors," say what that means for the
-
+milestone and outcome.
 - 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.
+Bad news reported early is manageable. Bad news discovered late damages
 confidence.
-The expected progression is:
+The goal is not to make every project look Green. It is to make
-
+leadership confident that you know what is happening and are managing
-```text
+it.
 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 changed?
- What should the project owner be responsible for maintaining?
+-   What is the health?
- What requires my intervention?
+-   What is the next milestone?
- What can be standardized across every project?
+-   Is the forecast credible?
- Is the process helping delivery, or merely creating administration?
+-   What is the main risk/blocker?
 -   What is the consequence?
 -   What decision/help is required?
 ## Meeting Scenario
-**Situation:**
+**Situation:** Your VP asks for an update on a project with a vendor
-
+blocker.
 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.
+> The project is Yellow. Development is complete, but vendor validation
 > is blocking Friday's production milestone. The vendor committed to a
 > fix tomorrow. If that slips, launch moves approximately one week. No
 > executive action is needed yet; I'll escalate if tomorrow's commitment
 > is missed.
 ## Key Takeaways
- The purpose of project management is predictable delivery, not documentation for its own sake.
+-   Report delivery, not activity.
- Project owners should own increasingly more of the planning and maintenance.
+-   Tailor detail to the audience.
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
+-   Lead with health and outcome.
- Every concept learned should eventually contribute to one lightweight common project template.
+-   Explain consequences.
- The final system should make exceptions and problems visible without requiring you to inspect every task.
+-   State decisions/help required.
 -   Early transparent reporting builds trust.
 ## Related Concepts
- [[Projects vs Operations]]
+-   \[\[Project Health\]\]
- [[Project Outcome]]
+-   \[\[Milestones vs Tasks\]\]
- [[Definition of Done]]
+-   \[\[Risk Management\]\]
- [[Scope]]
+-   \[\[Portfolio Management\]\]
 - [[Milestone]]
 - [[Dependencies]]
 - [[Capacity]]
 - [[Risk]]
 - [[Project Health]]
 - [[Portfolio Management]]