From 1033a565cb6b1cc1e86e53910e7c86f2643cfb6c Mon Sep 17 00:00:00 2001 From: Amadou Date: Thu, 23 Jul 2026 07:53:56 -0400 Subject: [PATCH] vault backup: 2026-07-23 07:53:56 --- .../Building My PM System.md | 103 +++ .../Project Management/Capacity and WIP.md | 103 +++ .../Project Management/Closing Projects.md | 103 +++ .../Project Management/Dependencies.md | 103 +++ .../Estimation and Forecasting.md | 103 +++ .../Meetings and Follow-up.md | 103 +++ .../Project Management/Milestones vs Tasks.md | 673 ++++++++++++++++++ .../Ownership and Delegation.md | 103 +++ .../Portfolio Management.md | 103 +++ .../Project Management/Prioritization.md | 103 +++ .../Project Management/Project Health.md | 103 +++ .../Project Management/Risk Management.md | 103 +++ .../Project Management/Status Reporting.md | 103 +++ .../Project Management/Table of Content.md | 73 ++ 14 files changed, 1982 insertions(+) create mode 100644 10 Knowledge/CTO Academy/Project Management/Building My PM System.md create mode 100644 10 Knowledge/CTO Academy/Project Management/Capacity and WIP.md create mode 100644 10 Knowledge/CTO Academy/Project Management/Closing Projects.md create mode 100644 10 Knowledge/CTO Academy/Project Management/Dependencies.md create mode 100644 10 Knowledge/CTO Academy/Project Management/Estimation and Forecasting.md create mode 100644 10 Knowledge/CTO Academy/Project Management/Meetings and Follow-up.md create mode 100644 10 Knowledge/CTO Academy/Project Management/Ownership and Delegation.md create mode 100644 10 Knowledge/CTO Academy/Project Management/Portfolio Management.md create mode 100644 10 Knowledge/CTO Academy/Project Management/Prioritization.md create mode 100644 10 Knowledge/CTO Academy/Project Management/Project Health.md create mode 100644 10 Knowledge/CTO Academy/Project Management/Risk Management.md create mode 100644 10 Knowledge/CTO Academy/Project Management/Status Reporting.md create mode 100644 10 Knowledge/CTO Academy/Project Management/Table of Content.md diff --git a/10 Knowledge/CTO Academy/Project Management/Building My PM System.md b/10 Knowledge/CTO Academy/Project Management/Building My PM System.md new file mode 100644 index 0000000..c1babb3 --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Building My PM System.md @@ -0,0 +1,103 @@ +# Building My PM System +Duration: 30–40 minutes + +## Definition + +Combine the course into a lightweight repeatable system for your team and Monday.com. + +This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. + +## Simple Mental Model + +The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. + +## How It Works + +We will examine this concept through four levels: + +1. What the concept means. +2. How a project owner should use it. +3. How you should review or challenge it as the manager. +4. How it should eventually appear in your project-management system. + +## Example + +The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. + +The objective is to move from theory to a repeatable management practice. + +## How It Fits Into the Bigger Picture + +The course builds progressively: + +- Project vs operations establishes what kind of work we are managing. +- Outcomes and Definition of Done establish what success means. +- Scope establishes the project's boundaries. +- Milestones establish meaningful progress. +- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. +- Status reporting, meetings, ownership, and portfolio management make the system scalable. +- Closing and the final PM system turn the concepts into an operating method. + +## My Company / Real-World Context + +Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. + +The lesson should therefore be applied to an environment where: + +- Project owners are usually members of your own team rather than dedicated PMs. +- Operational work regularly interrupts project work. +- Product and IT are important cross-functional partners. +- You need portfolio-level visibility without personally maintaining every task. +- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. + +## CTO Perspective + +The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. + +The expected progression is: + +```text +Contributor → manages tasks +Project Owner → drives milestones and delivery +Manager → manages projects, priorities, risks and escalation +Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` + +### Questions to Ask + +- What information do I need to make a management decision? +- What should the project owner be responsible for maintaining? +- What requires my intervention? +- What can be standardized across every project? +- Is the process helping delivery, or merely creating administration? + +## Meeting Scenario + +**Situation:** + +A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. + +**Possible response:** + +> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. + +## Key Takeaways + +- The purpose of project management is predictable delivery, not documentation for its own sake. +- Project owners should own increasingly more of the planning and maintenance. +- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. +- Every concept learned should eventually contribute to one lightweight common project template. +- The final system should make exceptions and problems visible without requiring you to inspect every task. + +## Related Concepts + +- [[Projects vs Operations]] +- [[Project Outcome]] +- [[Definition of Done]] +- [[Scope]] +- [[Milestone]] +- [[Dependencies]] +- [[Capacity]] +- [[Risk]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Capacity and WIP.md b/10 Knowledge/CTO Academy/Project Management/Capacity and WIP.md new file mode 100644 index 0000000..7f5aed5 --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Capacity and WIP.md @@ -0,0 +1,103 @@ +# Capacity and WIP +Duration: 30–40 minutes + +## Definition + +Plan around real team capacity, operational interruptions, and limits on concurrent work. + +This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. + +## Simple Mental Model + +The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. + +## How It Works + +We will examine this concept through four levels: + +1. What the concept means. +2. How a project owner should use it. +3. How you should review or challenge it as the manager. +4. How it should eventually appear in your project-management system. + +## Example + +The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. + +The objective is to move from theory to a repeatable management practice. + +## How It Fits Into the Bigger Picture + +The course builds progressively: + +- Project vs operations establishes what kind of work we are managing. +- Outcomes and Definition of Done establish what success means. +- Scope establishes the project's boundaries. +- Milestones establish meaningful progress. +- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. +- Status reporting, meetings, ownership, and portfolio management make the system scalable. +- Closing and the final PM system turn the concepts into an operating method. + +## My Company / Real-World Context + +Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. + +The lesson should therefore be applied to an environment where: + +- Project owners are usually members of your own team rather than dedicated PMs. +- Operational work regularly interrupts project work. +- Product and IT are important cross-functional partners. +- You need portfolio-level visibility without personally maintaining every task. +- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. + +## CTO Perspective + +The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. + +The expected progression is: + +```text +Contributor → manages tasks +Project Owner → drives milestones and delivery +Manager → manages projects, priorities, risks and escalation +Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` + +### Questions to Ask + +- What information do I need to make a management decision? +- What should the project owner be responsible for maintaining? +- What requires my intervention? +- What can be standardized across every project? +- Is the process helping delivery, or merely creating administration? + +## Meeting Scenario + +**Situation:** + +A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. + +**Possible response:** + +> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. + +## Key Takeaways + +- The purpose of project management is predictable delivery, not documentation for its own sake. +- Project owners should own increasingly more of the planning and maintenance. +- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. +- Every concept learned should eventually contribute to one lightweight common project template. +- The final system should make exceptions and problems visible without requiring you to inspect every task. + +## Related Concepts + +- [[Projects vs Operations]] +- [[Project Outcome]] +- [[Definition of Done]] +- [[Scope]] +- [[Milestone]] +- [[Dependencies]] +- [[Capacity]] +- [[Risk]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Closing Projects.md b/10 Knowledge/CTO Academy/Project Management/Closing Projects.md new file mode 100644 index 0000000..020e836 --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Closing Projects.md @@ -0,0 +1,103 @@ +# Closing Projects +Duration: 30–40 minutes + +## Definition + +Formally accept outcomes, hand work to operations, document lessons, and close projects. + +This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. + +## Simple Mental Model + +The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. + +## How It Works + +We will examine this concept through four levels: + +1. What the concept means. +2. How a project owner should use it. +3. How you should review or challenge it as the manager. +4. How it should eventually appear in your project-management system. + +## Example + +The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. + +The objective is to move from theory to a repeatable management practice. + +## How It Fits Into the Bigger Picture + +The course builds progressively: + +- Project vs operations establishes what kind of work we are managing. +- Outcomes and Definition of Done establish what success means. +- Scope establishes the project's boundaries. +- Milestones establish meaningful progress. +- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. +- Status reporting, meetings, ownership, and portfolio management make the system scalable. +- Closing and the final PM system turn the concepts into an operating method. + +## My Company / Real-World Context + +Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. + +The lesson should therefore be applied to an environment where: + +- Project owners are usually members of your own team rather than dedicated PMs. +- Operational work regularly interrupts project work. +- Product and IT are important cross-functional partners. +- You need portfolio-level visibility without personally maintaining every task. +- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. + +## CTO Perspective + +The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. + +The expected progression is: + +```text +Contributor → manages tasks +Project Owner → drives milestones and delivery +Manager → manages projects, priorities, risks and escalation +Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` + +### Questions to Ask + +- What information do I need to make a management decision? +- What should the project owner be responsible for maintaining? +- What requires my intervention? +- What can be standardized across every project? +- Is the process helping delivery, or merely creating administration? + +## Meeting Scenario + +**Situation:** + +A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. + +**Possible response:** + +> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. + +## Key Takeaways + +- The purpose of project management is predictable delivery, not documentation for its own sake. +- Project owners should own increasingly more of the planning and maintenance. +- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. +- Every concept learned should eventually contribute to one lightweight common project template. +- The final system should make exceptions and problems visible without requiring you to inspect every task. + +## Related Concepts + +- [[Projects vs Operations]] +- [[Project Outcome]] +- [[Definition of Done]] +- [[Scope]] +- [[Milestone]] +- [[Dependencies]] +- [[Capacity]] +- [[Risk]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Dependencies.md b/10 Knowledge/CTO Academy/Project Management/Dependencies.md new file mode 100644 index 0000000..d984e65 --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Dependencies.md @@ -0,0 +1,103 @@ +# Dependencies +Duration: 30–40 minutes + +## Definition + +Identify work, people, teams, vendors, and decisions that can block delivery. + +This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. + +## Simple Mental Model + +The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. + +## How It Works + +We will examine this concept through four levels: + +1. What the concept means. +2. How a project owner should use it. +3. How you should review or challenge it as the manager. +4. How it should eventually appear in your project-management system. + +## Example + +The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. + +The objective is to move from theory to a repeatable management practice. + +## How It Fits Into the Bigger Picture + +The course builds progressively: + +- Project vs operations establishes what kind of work we are managing. +- Outcomes and Definition of Done establish what success means. +- Scope establishes the project's boundaries. +- Milestones establish meaningful progress. +- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. +- Status reporting, meetings, ownership, and portfolio management make the system scalable. +- Closing and the final PM system turn the concepts into an operating method. + +## My Company / Real-World Context + +Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. + +The lesson should therefore be applied to an environment where: + +- Project owners are usually members of your own team rather than dedicated PMs. +- Operational work regularly interrupts project work. +- Product and IT are important cross-functional partners. +- You need portfolio-level visibility without personally maintaining every task. +- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. + +## CTO Perspective + +The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. + +The expected progression is: + +```text +Contributor → manages tasks +Project Owner → drives milestones and delivery +Manager → manages projects, priorities, risks and escalation +Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` + +### Questions to Ask + +- What information do I need to make a management decision? +- What should the project owner be responsible for maintaining? +- What requires my intervention? +- What can be standardized across every project? +- Is the process helping delivery, or merely creating administration? + +## Meeting Scenario + +**Situation:** + +A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. + +**Possible response:** + +> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. + +## Key Takeaways + +- The purpose of project management is predictable delivery, not documentation for its own sake. +- Project owners should own increasingly more of the planning and maintenance. +- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. +- Every concept learned should eventually contribute to one lightweight common project template. +- The final system should make exceptions and problems visible without requiring you to inspect every task. + +## Related Concepts + +- [[Projects vs Operations]] +- [[Project Outcome]] +- [[Definition of Done]] +- [[Scope]] +- [[Milestone]] +- [[Dependencies]] +- [[Capacity]] +- [[Risk]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Estimation and Forecasting.md b/10 Knowledge/CTO Academy/Project Management/Estimation and Forecasting.md new file mode 100644 index 0000000..f68c16c --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Estimation and Forecasting.md @@ -0,0 +1,103 @@ +# Estimation and Forecasting +Duration: 30–40 minutes + +## Definition + +Build realistic estimates and distinguish estimates, targets, and commitments. + +This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. + +## Simple Mental Model + +The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. + +## How It Works + +We will examine this concept through four levels: + +1. What the concept means. +2. How a project owner should use it. +3. How you should review or challenge it as the manager. +4. How it should eventually appear in your project-management system. + +## Example + +The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. + +The objective is to move from theory to a repeatable management practice. + +## How It Fits Into the Bigger Picture + +The course builds progressively: + +- Project vs operations establishes what kind of work we are managing. +- Outcomes and Definition of Done establish what success means. +- Scope establishes the project's boundaries. +- Milestones establish meaningful progress. +- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. +- Status reporting, meetings, ownership, and portfolio management make the system scalable. +- Closing and the final PM system turn the concepts into an operating method. + +## My Company / Real-World Context + +Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. + +The lesson should therefore be applied to an environment where: + +- Project owners are usually members of your own team rather than dedicated PMs. +- Operational work regularly interrupts project work. +- Product and IT are important cross-functional partners. +- You need portfolio-level visibility without personally maintaining every task. +- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. + +## CTO Perspective + +The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. + +The expected progression is: + +```text +Contributor → manages tasks +Project Owner → drives milestones and delivery +Manager → manages projects, priorities, risks and escalation +Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` + +### Questions to Ask + +- What information do I need to make a management decision? +- What should the project owner be responsible for maintaining? +- What requires my intervention? +- What can be standardized across every project? +- Is the process helping delivery, or merely creating administration? + +## Meeting Scenario + +**Situation:** + +A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. + +**Possible response:** + +> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. + +## Key Takeaways + +- The purpose of project management is predictable delivery, not documentation for its own sake. +- Project owners should own increasingly more of the planning and maintenance. +- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. +- Every concept learned should eventually contribute to one lightweight common project template. +- The final system should make exceptions and problems visible without requiring you to inspect every task. + +## Related Concepts + +- [[Projects vs Operations]] +- [[Project Outcome]] +- [[Definition of Done]] +- [[Scope]] +- [[Milestone]] +- [[Dependencies]] +- [[Capacity]] +- [[Risk]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Meetings and Follow-up.md b/10 Knowledge/CTO Academy/Project Management/Meetings and Follow-up.md new file mode 100644 index 0000000..f50e291 --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Meetings and Follow-up.md @@ -0,0 +1,103 @@ +# Meetings and Follow-up +Duration: 30–40 minutes + +## Definition + +Run project meetings around decisions, blockers, ownership, and next actions. + +This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. + +## Simple Mental Model + +The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. + +## How It Works + +We will examine this concept through four levels: + +1. What the concept means. +2. How a project owner should use it. +3. How you should review or challenge it as the manager. +4. How it should eventually appear in your project-management system. + +## Example + +The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. + +The objective is to move from theory to a repeatable management practice. + +## How It Fits Into the Bigger Picture + +The course builds progressively: + +- Project vs operations establishes what kind of work we are managing. +- Outcomes and Definition of Done establish what success means. +- Scope establishes the project's boundaries. +- Milestones establish meaningful progress. +- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. +- Status reporting, meetings, ownership, and portfolio management make the system scalable. +- Closing and the final PM system turn the concepts into an operating method. + +## My Company / Real-World Context + +Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. + +The lesson should therefore be applied to an environment where: + +- Project owners are usually members of your own team rather than dedicated PMs. +- Operational work regularly interrupts project work. +- Product and IT are important cross-functional partners. +- You need portfolio-level visibility without personally maintaining every task. +- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. + +## CTO Perspective + +The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. + +The expected progression is: + +```text +Contributor → manages tasks +Project Owner → drives milestones and delivery +Manager → manages projects, priorities, risks and escalation +Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` + +### Questions to Ask + +- What information do I need to make a management decision? +- What should the project owner be responsible for maintaining? +- What requires my intervention? +- What can be standardized across every project? +- Is the process helping delivery, or merely creating administration? + +## Meeting Scenario + +**Situation:** + +A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. + +**Possible response:** + +> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. + +## Key Takeaways + +- The purpose of project management is predictable delivery, not documentation for its own sake. +- Project owners should own increasingly more of the planning and maintenance. +- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. +- Every concept learned should eventually contribute to one lightweight common project template. +- The final system should make exceptions and problems visible without requiring you to inspect every task. + +## Related Concepts + +- [[Projects vs Operations]] +- [[Project Outcome]] +- [[Definition of Done]] +- [[Scope]] +- [[Milestone]] +- [[Dependencies]] +- [[Capacity]] +- [[Risk]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Milestones vs Tasks.md b/10 Knowledge/CTO Academy/Project Management/Milestones vs Tasks.md index e69de29..fc4fd74 100644 --- a/10 Knowledge/CTO Academy/Project Management/Milestones vs Tasks.md +++ b/10 Knowledge/CTO Academy/Project Management/Milestones vs Tasks.md @@ -0,0 +1,673 @@ +Duration: 30–35 minutes + +## Definition + +A **task** is a specific piece of work that needs to be performed. + +A **milestone** is a significant checkpoint that demonstrates meaningful progress toward the project's outcome. + +The distinction matters because managers can easily drown in hundreds of tasks when what they actually need to understand is: + +> **Is the project progressing toward its outcome?** + +### Task + +Examples: + +- Configure DNS + +- Create database + +- Implement tracking script + +- Write test cases + +- Review documentation + +- Configure deployment pipeline + + +Tasks represent **work**. + +### Milestone + +Examples: + +- Infrastructure ready + +- Tracking implementation complete + +- Data validation approved + +- Production launch complete + +- Operational handoff complete + + +Milestones represent **meaningful states reached by the project**. + +--- + +## Simple Mental Model + +Think: + +> **Tasks tell the team what to do.** +> **Milestones tell the manager where the project is.** + +Or: + +```text +TASKS → TASKS → TASKS → MILESTONE + ↓ +TASKS → TASKS → TASKS → MILESTONE + ↓ +TASKS → TASKS → TASKS → PROJECT DONE +``` + +You don't necessarily need to know whether task #37 is complete. + +You often need to know: + +> "Have we reached the production-ready milestone?" + +--- + +## How It Works + +Consider a project to implement Umami. + +The project could contain dozens of tasks: + +```text +- Create server +- Configure database +- Configure DNS +- Configure SSL +- Deploy Umami +- Configure authentication +- Add tracking script +- Configure events +- Test page views +- Test custom events +- Validate traffic +- Compare data +- Create dashboard +- Write documentation +- Train users +... +``` + +All legitimate work. + +But imagine you're managing 12 projects. + +You cannot effectively manage: + +> 15 tasks × 12 projects = 180 individual tasks + +And that's a small example. + +Instead, you might manage Umami through five milestones: + +```text +1. Infrastructure ready + ↓ +2. Tracking implemented + ↓ +3. Data validated + ↓ +4. Reporting available + ↓ +5. Production handoff complete +``` + +The project owner manages the tasks required to reach those milestones. + +You manage primarily through the milestones. + +--- + +## What Makes a Good Milestone? + +A milestone should represent a **meaningful state**, not merely arbitrary progress. + +Weak: + +> 50% development complete + +Better: + +> Tracking implementation complete and ready for QA + +Weak: + +> Worked on infrastructure + +Better: + +> Production infrastructure ready + +Weak: + +> Meeting with Product completed + +Better: + +> Requirements approved by Product + +The second versions tell you something important about the project's state. + +--- + +### Milestones should be verifiable + +Someone should be able to ask: + +> "Did we reach this milestone?" + +and get a reasonably objective answer. + +For example: + +> **Data validation complete** + +means agreed validation has occurred and the results were accepted. + +Compare that with: + +> **Data validation underway** + +That's a status, not a milestone. + +--- + +## Example + +Let's use your **Pipeline QA d'automatisation** project. + +### Outcome + +> Critical website functionality can be automatically validated before production releases, reducing manual QA effort and identifying regressions earlier. + +### Possible Milestones + +**Milestone 1: Requirements approved** + +The team agrees on: + +- Which user journeys are critical + +- What should be automated + +- What remains manual + + +--- + +**Milestone 2: Proof of concept validated** + +A small number of tests successfully run automatically. + +This reduces an important uncertainty: + +> Can our proposed approach actually work? + +--- + +**Milestone 3: Critical test suite complete** + +The agreed critical scenarios have been automated. + +--- + +**Milestone 4: Deployment integration complete** + +Tests run as part of the agreed deployment workflow. + +--- + +**Milestone 5: QA acceptance complete** + +QA validates that the automation meets the agreed requirements. + +--- + +**Milestone 6: Operational handoff complete** + +Documentation exists, ownership is established, and the system can move from project work into operations. + +Now compare that with: + +> Project is 70% complete. + +"70%" tells you surprisingly little. + +Knowing: + +> "The critical test suite is complete, but deployment integration hasn't started" + +tells you much more. + +--- + +## How It Fits Into the Bigger Picture + +The first four lessons now build directly on each other. + +### [[Projects vs Operations]] + +> Is this temporary work? + +### [[Outcomes and Definition of Done]] + +> What are we trying to accomplish, and what counts as finished? + +### [[Scope and Scope Creep]] + +> What work belongs inside the project? + +### [[Milestones vs Tasks]] + +> What meaningful checkpoints show us that we're getting there? + +Together: + +```text + OUTCOME + │ + Where are we going? + │ + ▼ + SCOPE + │ + What are we delivering? + │ + ▼ + MILESTONES + │ + How do we know we're + making progress? + │ + ▼ + TASKS + │ + What needs doing? + │ + ▼ + DEFINITION OF DONE +``` + +This order is important. + +A common mistake is starting immediately with: + +> "Let's create all the Jira tasks." + +But you haven't necessarily established what the project is trying to accomplish yet. + +--- + +## My Company / Real-World Context + +This concept is particularly relevant to how you should eventually divide responsibility between yourself and your project owners. + +You shouldn't need to manage every task performed by your integrators, analysts, QA, or SEO/WCAG person. + +The eventual system could look like: + +```text +PROJECT OWNER +│ +├── Tasks +├── Detailed sequencing +├── Day-to-day follow-up +└── Contributors + │ + ▼ + MILESTONES + │ + ▼ + YOU +``` + +The project owner should be able to tell you: + +> "We're targeting milestone 3 for August 15." + +Your job becomes asking: + +> "Are we still going to hit August 15?" + +rather than: + +> "Did Jean complete Jira ticket ABC-234?" + +That is a significant difference between **managing projects** and **managing people's task lists**. + +--- + +### Your Monday board + +This also gives us our first clue about what might eventually change in Monday. + +Your current portfolio has broad timelines. + +For example: + +```text +Suppression de Mogador +April 2026 ───────────────── January 2027 +``` + +That tells you the project exists for approximately nine months. + +But imagine instead seeing: + +```text +Suppression de Mogador + +Health: 🟡 + +Current milestone: +Replacement synchronization validated + +Target: +September 15 + +Next milestone: +Production cutover + +Target: +October 10 +``` + +Suddenly you can understand the project without opening its entire task list. + +We aren't modifying Monday yet, but this is one concept that will eventually influence the design. + +--- + +## Milestones and Dates + +Milestones usually have target dates. + +This is where something important happens with the problem you've already identified: + +> Your projects frequently get interrupted by operations. + +Suppose: + +```text +Milestone: +Tracking implementation complete + +Target: +August 15 +``` + +August 15 arrives. + +The milestone isn't complete because the owner spent eight days dealing with production incidents. + +Don't simply change: + +> August 15 → August 30 + +and move on. + +The missed milestone contains **management information**. + +You want to understand: + +> Why did we miss it? + +Possible reasons: + +- Scope increased + +- Estimate was wrong + +- Operational interruptions + +- Dependency wasn't available + +- Owner didn't execute + +- Requirements weren't clear + +- Priority changed + +- Technical problem appeared + + +Those causes require completely different management responses. + +A milestone isn't only a deadline. + +It creates a **checkpoint where reality meets the plan**. + +--- + +## Milestone vs Deadline + +They're related but not identical. + +A **deadline** says: + +> Something must happen by this date. + +A **milestone** says: + +> The project has reached this meaningful state. + +A milestone commonly has a target date: + +> **Milestone:** Data validation complete +> **Target:** September 30 + +This gives you both: + +**What should be true + when we expect it to be true.** + +--- + +## CTO Perspective + +As you move higher in an organization, the level at which you manage should change. + +An integrator might think about: + +> What code needs to be written today? + +A project owner might think about: + +> What work needs to happen to reach the next milestone? + +You might think about: + +> Which projects aren't reaching their milestones? + +A CTO might think about: + +> Which strategic initiatives aren't delivering their expected outcomes? + +Think of it as levels: + +```text +EXECUTIVE +Outcomes + ↑ +YOU +Projects / Milestones + ↑ +PROJECT OWNER +Milestones / Tasks + ↑ +CONTRIBUTOR +Tasks +``` + +This doesn't mean a CTO never looks at a task. + +It means they **shouldn't need to manage through tasks under normal circumstances**. + +--- + +### Milestones also create accountability + +Suppose one of your project owners says: + +> "The project is going well." + +Your response can be: + +> "What's the next milestone?" + +They answer: + +> "Data validation." + +You ask: + +> "When?" + +> "August 20." + +Then August 20 gives you an objective point to review. + +Without milestones, project updates easily become: + +> "Still working on it." + +> "Making progress." + +> "Almost there." + +> "Waiting on a couple things." + +Those statements are difficult to manage. + +--- + +### Don't create too many milestones + +Milestones are supposed to simplify project visibility. + +A three-month project probably doesn't need 25 milestones. + +If every task becomes a milestone, you've recreated the task list. + +A useful starting point might be around **3–7 meaningful milestones** for many of your projects, depending on size and complexity. + +The exact number isn't the important part. + +Ask: + +> **Would I care if this checkpoint wasn't reached?** + +If not, it probably doesn't need to be a portfolio-level milestone. + +--- + +### Questions to Ask + +- What are the major states this project must pass through before completion? + +- What's the next milestone? + +- Who owns reaching it? + +- What's its target date? + +- What must be true before we consider the milestone achieved? + +- Are we still confident in the target? + +- What could prevent us from reaching it? + +- If we missed it, why? + +- Was the cause scope, capacity, dependency, execution, or something else? + +- Am I managing the project through meaningful checkpoints or micromanaging individual tasks? + + +--- + +## Meeting Scenario + +**Situation:** + +You ask a project owner: + +> "How's the project going?" + +They respond: + +> "Pretty good. We completed about 18 tickets. There's still quite a bit left, but we're making progress." + +This gives you very little useful information. + +**Possible response:** + +> What's the next milestone we're trying to reach, and are we still on track for its target date? + +They respond: + +> "The next milestone is production data validation on September 15. Development is nearly complete, but we're waiting on DevOps for the production environment, so September 15 is currently at risk." + +Now you have something actionable. + +The problem isn't: + +> "18 tickets completed." + +The management information is: + +> **Milestone at risk because of a cross-team dependency.** + +And because DevOps doesn't report to the project owner, that may be exactly the type of problem that should come to **you**. + +--- + +## Key Takeaways + +- **Tasks represent work. Milestones represent meaningful progress.** + +- Project owners should generally manage detailed tasks. + +- Managers should primarily manage projects through outcomes, milestones, risks, and blockers. + +- Good milestones describe verifiable states such as "QA accepted" rather than vague activity such as "working on QA." + +- Milestones should usually have target dates. + +- A missed milestone is useful management information and should trigger understanding of **why** it was missed. + +- Don't automatically move milestone dates without understanding the cause. + +- Too many milestones defeats their purpose. + +- Milestones help you manage multiple projects without micromanaging every task. + +- As leadership responsibility increases, management should increasingly move from **tasks → milestones → outcomes**. + + +## Related Concepts + +- [[Projects vs Operations]] + +- [[Outcomes and Definition of Done]] + +- [[Scope and Scope Creep]] + +- [[Milestones vs Tasks]] + +- [[Dependencies]] + +- [[Capacity and WIP]] + +- [[Project Health]] + +- [[Portfolio Management]] \ No newline at end of file diff --git a/10 Knowledge/CTO Academy/Project Management/Ownership and Delegation.md b/10 Knowledge/CTO Academy/Project Management/Ownership and Delegation.md new file mode 100644 index 0000000..5462ccb --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Ownership and Delegation.md @@ -0,0 +1,103 @@ +# Ownership and Delegation +Duration: 30–40 minutes + +## Definition + +Make project ownership clear and develop team members who can drive projects. + +This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. + +## Simple Mental Model + +The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. + +## How It Works + +We will examine this concept through four levels: + +1. What the concept means. +2. How a project owner should use it. +3. How you should review or challenge it as the manager. +4. How it should eventually appear in your project-management system. + +## Example + +The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. + +The objective is to move from theory to a repeatable management practice. + +## How It Fits Into the Bigger Picture + +The course builds progressively: + +- Project vs operations establishes what kind of work we are managing. +- Outcomes and Definition of Done establish what success means. +- Scope establishes the project's boundaries. +- Milestones establish meaningful progress. +- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. +- Status reporting, meetings, ownership, and portfolio management make the system scalable. +- Closing and the final PM system turn the concepts into an operating method. + +## My Company / Real-World Context + +Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. + +The lesson should therefore be applied to an environment where: + +- Project owners are usually members of your own team rather than dedicated PMs. +- Operational work regularly interrupts project work. +- Product and IT are important cross-functional partners. +- You need portfolio-level visibility without personally maintaining every task. +- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. + +## CTO Perspective + +The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. + +The expected progression is: + +```text +Contributor → manages tasks +Project Owner → drives milestones and delivery +Manager → manages projects, priorities, risks and escalation +Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` + +### Questions to Ask + +- What information do I need to make a management decision? +- What should the project owner be responsible for maintaining? +- What requires my intervention? +- What can be standardized across every project? +- Is the process helping delivery, or merely creating administration? + +## Meeting Scenario + +**Situation:** + +A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. + +**Possible response:** + +> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. + +## Key Takeaways + +- The purpose of project management is predictable delivery, not documentation for its own sake. +- Project owners should own increasingly more of the planning and maintenance. +- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. +- Every concept learned should eventually contribute to one lightweight common project template. +- The final system should make exceptions and problems visible without requiring you to inspect every task. + +## Related Concepts + +- [[Projects vs Operations]] +- [[Project Outcome]] +- [[Definition of Done]] +- [[Scope]] +- [[Milestone]] +- [[Dependencies]] +- [[Capacity]] +- [[Risk]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Portfolio Management.md b/10 Knowledge/CTO Academy/Project Management/Portfolio Management.md new file mode 100644 index 0000000..b968805 --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Portfolio Management.md @@ -0,0 +1,103 @@ +# Portfolio Management +Duration: 30–40 minutes + +## Definition + +Manage the collection of projects as a system rather than independently. + +This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. + +## Simple Mental Model + +The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. + +## How It Works + +We will examine this concept through four levels: + +1. What the concept means. +2. How a project owner should use it. +3. How you should review or challenge it as the manager. +4. How it should eventually appear in your project-management system. + +## Example + +The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. + +The objective is to move from theory to a repeatable management practice. + +## How It Fits Into the Bigger Picture + +The course builds progressively: + +- Project vs operations establishes what kind of work we are managing. +- Outcomes and Definition of Done establish what success means. +- Scope establishes the project's boundaries. +- Milestones establish meaningful progress. +- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. +- Status reporting, meetings, ownership, and portfolio management make the system scalable. +- Closing and the final PM system turn the concepts into an operating method. + +## My Company / Real-World Context + +Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. + +The lesson should therefore be applied to an environment where: + +- Project owners are usually members of your own team rather than dedicated PMs. +- Operational work regularly interrupts project work. +- Product and IT are important cross-functional partners. +- You need portfolio-level visibility without personally maintaining every task. +- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. + +## CTO Perspective + +The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. + +The expected progression is: + +```text +Contributor → manages tasks +Project Owner → drives milestones and delivery +Manager → manages projects, priorities, risks and escalation +Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` + +### Questions to Ask + +- What information do I need to make a management decision? +- What should the project owner be responsible for maintaining? +- What requires my intervention? +- What can be standardized across every project? +- Is the process helping delivery, or merely creating administration? + +## Meeting Scenario + +**Situation:** + +A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. + +**Possible response:** + +> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. + +## Key Takeaways + +- The purpose of project management is predictable delivery, not documentation for its own sake. +- Project owners should own increasingly more of the planning and maintenance. +- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. +- Every concept learned should eventually contribute to one lightweight common project template. +- The final system should make exceptions and problems visible without requiring you to inspect every task. + +## Related Concepts + +- [[Projects vs Operations]] +- [[Project Outcome]] +- [[Definition of Done]] +- [[Scope]] +- [[Milestone]] +- [[Dependencies]] +- [[Capacity]] +- [[Risk]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Prioritization.md b/10 Knowledge/CTO Academy/Project Management/Prioritization.md new file mode 100644 index 0000000..1f85915 --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Prioritization.md @@ -0,0 +1,103 @@ +# Prioritization +Duration: 30–40 minutes + +## Definition + +Decide what should be worked on now when everything appears important. + +This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. + +## Simple Mental Model + +The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. + +## How It Works + +We will examine this concept through four levels: + +1. What the concept means. +2. How a project owner should use it. +3. How you should review or challenge it as the manager. +4. How it should eventually appear in your project-management system. + +## Example + +The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. + +The objective is to move from theory to a repeatable management practice. + +## How It Fits Into the Bigger Picture + +The course builds progressively: + +- Project vs operations establishes what kind of work we are managing. +- Outcomes and Definition of Done establish what success means. +- Scope establishes the project's boundaries. +- Milestones establish meaningful progress. +- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. +- Status reporting, meetings, ownership, and portfolio management make the system scalable. +- Closing and the final PM system turn the concepts into an operating method. + +## My Company / Real-World Context + +Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. + +The lesson should therefore be applied to an environment where: + +- Project owners are usually members of your own team rather than dedicated PMs. +- Operational work regularly interrupts project work. +- Product and IT are important cross-functional partners. +- You need portfolio-level visibility without personally maintaining every task. +- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. + +## CTO Perspective + +The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. + +The expected progression is: + +```text +Contributor → manages tasks +Project Owner → drives milestones and delivery +Manager → manages projects, priorities, risks and escalation +Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` + +### Questions to Ask + +- What information do I need to make a management decision? +- What should the project owner be responsible for maintaining? +- What requires my intervention? +- What can be standardized across every project? +- Is the process helping delivery, or merely creating administration? + +## Meeting Scenario + +**Situation:** + +A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. + +**Possible response:** + +> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. + +## Key Takeaways + +- The purpose of project management is predictable delivery, not documentation for its own sake. +- Project owners should own increasingly more of the planning and maintenance. +- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. +- Every concept learned should eventually contribute to one lightweight common project template. +- The final system should make exceptions and problems visible without requiring you to inspect every task. + +## Related Concepts + +- [[Projects vs Operations]] +- [[Project Outcome]] +- [[Definition of Done]] +- [[Scope]] +- [[Milestone]] +- [[Dependencies]] +- [[Capacity]] +- [[Risk]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Project Health.md b/10 Knowledge/CTO Academy/Project Management/Project Health.md new file mode 100644 index 0000000..4b1f363 --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Project Health.md @@ -0,0 +1,103 @@ +# Project Health +Duration: 30–40 minutes + +## Definition + +Use evidence to classify projects as healthy, at risk, or off track. + +This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. + +## Simple Mental Model + +The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. + +## How It Works + +We will examine this concept through four levels: + +1. What the concept means. +2. How a project owner should use it. +3. How you should review or challenge it as the manager. +4. How it should eventually appear in your project-management system. + +## Example + +The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. + +The objective is to move from theory to a repeatable management practice. + +## How It Fits Into the Bigger Picture + +The course builds progressively: + +- Project vs operations establishes what kind of work we are managing. +- Outcomes and Definition of Done establish what success means. +- Scope establishes the project's boundaries. +- Milestones establish meaningful progress. +- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. +- Status reporting, meetings, ownership, and portfolio management make the system scalable. +- Closing and the final PM system turn the concepts into an operating method. + +## My Company / Real-World Context + +Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. + +The lesson should therefore be applied to an environment where: + +- Project owners are usually members of your own team rather than dedicated PMs. +- Operational work regularly interrupts project work. +- Product and IT are important cross-functional partners. +- You need portfolio-level visibility without personally maintaining every task. +- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. + +## CTO Perspective + +The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. + +The expected progression is: + +```text +Contributor → manages tasks +Project Owner → drives milestones and delivery +Manager → manages projects, priorities, risks and escalation +Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` + +### Questions to Ask + +- What information do I need to make a management decision? +- What should the project owner be responsible for maintaining? +- What requires my intervention? +- What can be standardized across every project? +- Is the process helping delivery, or merely creating administration? + +## Meeting Scenario + +**Situation:** + +A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. + +**Possible response:** + +> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. + +## Key Takeaways + +- The purpose of project management is predictable delivery, not documentation for its own sake. +- Project owners should own increasingly more of the planning and maintenance. +- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. +- Every concept learned should eventually contribute to one lightweight common project template. +- The final system should make exceptions and problems visible without requiring you to inspect every task. + +## Related Concepts + +- [[Projects vs Operations]] +- [[Project Outcome]] +- [[Definition of Done]] +- [[Scope]] +- [[Milestone]] +- [[Dependencies]] +- [[Capacity]] +- [[Risk]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Risk Management.md b/10 Knowledge/CTO Academy/Project Management/Risk Management.md new file mode 100644 index 0000000..6b47334 --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Risk Management.md @@ -0,0 +1,103 @@ +# Risk Management +Duration: 30–40 minutes + +## Definition + +Identify, assess, mitigate, and monitor risks before they become project problems. + +This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. + +## Simple Mental Model + +The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. + +## How It Works + +We will examine this concept through four levels: + +1. What the concept means. +2. How a project owner should use it. +3. How you should review or challenge it as the manager. +4. How it should eventually appear in your project-management system. + +## Example + +The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. + +The objective is to move from theory to a repeatable management practice. + +## How It Fits Into the Bigger Picture + +The course builds progressively: + +- Project vs operations establishes what kind of work we are managing. +- Outcomes and Definition of Done establish what success means. +- Scope establishes the project's boundaries. +- Milestones establish meaningful progress. +- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. +- Status reporting, meetings, ownership, and portfolio management make the system scalable. +- Closing and the final PM system turn the concepts into an operating method. + +## My Company / Real-World Context + +Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. + +The lesson should therefore be applied to an environment where: + +- Project owners are usually members of your own team rather than dedicated PMs. +- Operational work regularly interrupts project work. +- Product and IT are important cross-functional partners. +- You need portfolio-level visibility without personally maintaining every task. +- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. + +## CTO Perspective + +The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. + +The expected progression is: + +```text +Contributor → manages tasks +Project Owner → drives milestones and delivery +Manager → manages projects, priorities, risks and escalation +Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` + +### Questions to Ask + +- What information do I need to make a management decision? +- What should the project owner be responsible for maintaining? +- What requires my intervention? +- What can be standardized across every project? +- Is the process helping delivery, or merely creating administration? + +## Meeting Scenario + +**Situation:** + +A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. + +**Possible response:** + +> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. + +## Key Takeaways + +- The purpose of project management is predictable delivery, not documentation for its own sake. +- Project owners should own increasingly more of the planning and maintenance. +- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. +- Every concept learned should eventually contribute to one lightweight common project template. +- The final system should make exceptions and problems visible without requiring you to inspect every task. + +## Related Concepts + +- [[Projects vs Operations]] +- [[Project Outcome]] +- [[Definition of Done]] +- [[Scope]] +- [[Milestone]] +- [[Dependencies]] +- [[Capacity]] +- [[Risk]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Status Reporting.md b/10 Knowledge/CTO Academy/Project Management/Status Reporting.md new file mode 100644 index 0000000..b17f956 --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Status Reporting.md @@ -0,0 +1,103 @@ +# Status Reporting +Duration: 30–40 minutes + +## Definition + +Communicate project status concisely to managers, executives, and stakeholders. + +This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. + +## Simple Mental Model + +The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. + +## How It Works + +We will examine this concept through four levels: + +1. What the concept means. +2. How a project owner should use it. +3. How you should review or challenge it as the manager. +4. How it should eventually appear in your project-management system. + +## Example + +The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. + +The objective is to move from theory to a repeatable management practice. + +## How It Fits Into the Bigger Picture + +The course builds progressively: + +- Project vs operations establishes what kind of work we are managing. +- Outcomes and Definition of Done establish what success means. +- Scope establishes the project's boundaries. +- Milestones establish meaningful progress. +- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. +- Status reporting, meetings, ownership, and portfolio management make the system scalable. +- Closing and the final PM system turn the concepts into an operating method. + +## My Company / Real-World Context + +Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. + +The lesson should therefore be applied to an environment where: + +- Project owners are usually members of your own team rather than dedicated PMs. +- Operational work regularly interrupts project work. +- Product and IT are important cross-functional partners. +- You need portfolio-level visibility without personally maintaining every task. +- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. + +## CTO Perspective + +The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. + +The expected progression is: + +```text +Contributor → manages tasks +Project Owner → drives milestones and delivery +Manager → manages projects, priorities, risks and escalation +Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` + +### Questions to Ask + +- What information do I need to make a management decision? +- What should the project owner be responsible for maintaining? +- What requires my intervention? +- What can be standardized across every project? +- Is the process helping delivery, or merely creating administration? + +## Meeting Scenario + +**Situation:** + +A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. + +**Possible response:** + +> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. + +## Key Takeaways + +- The purpose of project management is predictable delivery, not documentation for its own sake. +- Project owners should own increasingly more of the planning and maintenance. +- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. +- Every concept learned should eventually contribute to one lightweight common project template. +- The final system should make exceptions and problems visible without requiring you to inspect every task. + +## Related Concepts + +- [[Projects vs Operations]] +- [[Project Outcome]] +- [[Definition of Done]] +- [[Scope]] +- [[Milestone]] +- [[Dependencies]] +- [[Capacity]] +- [[Risk]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Table of Content.md b/10 Knowledge/CTO Academy/Project Management/Table of Content.md new file mode 100644 index 0000000..87cd947 --- /dev/null +++ b/10 Knowledge/CTO Academy/Project Management/Table of Content.md @@ -0,0 +1,73 @@ +# Project Management + +## Course Progress + +- [x] [[Projects vs Operations]] +- [x] [[Outcomes and Definition of Done]] +- [x] [[Scope and Scope Creep]] +- [x] [[Milestones vs Tasks]] +- [ ] [[Dependencies]] +- [ ] [[Estimation and Forecasting]] +- [ ] [[Prioritization]] +- [ ] [[Capacity and WIP]] +- [ ] [[Risk Management]] +- [ ] [[Project Health]] +- [ ] [[Status Reporting]] +- [ ] [[Meetings and Follow-up]] +- [ ] [[Ownership and Delegation]] +- [ ] [[Portfolio Management]] +- [ ] [[Closing Projects]] +- [ ] [[Building My PM System]] + +--- + +## Learning Path + +### Foundation + +1. [[Projects vs Operations]] +2. [[Outcomes and Definition of Done]] +3. [[Scope and Scope Creep]] +4. [[Milestones vs Tasks]] + +### Planning and Delivery + +5. [[Dependencies]] +6. [[Estimation and Forecasting]] +7. [[Prioritization]] +8. [[Capacity and WIP]] +9. [[Risk Management]] + +### Managing Projects + +10. [[Project Health]] +11. [[Status Reporting]] +12. [[Meetings and Follow-up]] +13. [[Ownership and Delegation]] + +### Managing the Portfolio + +14. [[Portfolio Management]] +15. [[Closing Projects]] + +### Build the System + +16. [[Building My PM System]] + +--- + +## End Goal + +Build a repeatable project management system where: + +- Every project has a clear outcome and Definition of Done. +- Scope and major milestones are agreed before commitment. +- A project owner within the team drives each project. +- Project owners maintain their own project information. +- Dependencies, risks and blockers become visible early. +- Estimates account for actual capacity and operational interruptions. +- Scope changes result in explicit trade-offs. +- I manage through milestones and outcomes rather than individual tasks. +- Project health tells me where my intervention is required. +- The portfolio shows what the team has committed to and whether we have capacity for more work. +- Monday.com becomes a management tool rather than a project list that nobody updates. \ No newline at end of file