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 index c1babb3..ae0aded 100644 --- a/10 Knowledge/CTO Academy/Project Management/Building My PM System.md +++ b/10 Knowledge/CTO Academy/Project Management/Building My PM System.md @@ -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. -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. +``` markdown +# Project Name + +## 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: - -- 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. +``` text +Projects vs Operations + ↓ +Outcome + DoD + ↓ +Scope + ↓ +Milestones + ↓ +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. -- 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. +> **Project owner maintains project truth.** + +You maintain: + +> **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 -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 -``` +> Do I know what is happening because I attended every meeting? + +It is: + +> 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? -- 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? +- Does every project have one owner? +- 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? +- Are we starting too much? +- Which projects can close? +- Is Monday helping decisions or merely storing information? ## Meeting Scenario -**Situation:** - -A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. +**Situation:** You open Monday after two weeks and several projects are +stale because you are still expected to update everything. **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. -- 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. +- Build one lightweight common project method. +- Owners maintain project-level information. +- You maintain priorities, capacity, portfolio health, and escalation. +- Monday becomes the portfolio source of truth. +- 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]] -- [[Project Outcome]] -- [[Definition of Done]] -- [[Scope]] -- [[Milestone]] -- [[Dependencies]] -- [[Capacity]] -- [[Risk]] -- [[Project Health]] -- [[Portfolio Management]] +- \[\[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\]\] +- \[\[Status Reporting\]\] +- \[\[Meetings and Follow-up\]\] +- \[\[Ownership and Delegation\]\] +- \[\[Portfolio Management\]\] +- \[\[Closing Projects\]\] diff --git a/10 Knowledge/CTO Academy/Project Management/Capacity and WIP.md b/10 Knowledge/CTO Academy/Project Management/Capacity and WIP.md index 7f5aed5..23f8eed 100644 --- a/10 Knowledge/CTO Academy/Project Management/Capacity and WIP.md +++ b/10 Knowledge/CTO Academy/Project Management/Capacity and WIP.md @@ -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. - -This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. +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 +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 -Project Owner → drives milestones and delivery -Manager → manages projects, priorities, risks and escalation -Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` text +35 hours +├── 10h operations/tickets +├── 5h meetings/admin +├── 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? -- 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? +- How much project capacity do we actually have? +- What percentage is regularly consumed by operations? +- How many projects are active per owner? +- Which role is the bottleneck? +- 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:** - -> 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. +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]] -- [[Project Outcome]] -- [[Definition of Done]] -- [[Scope]] -- [[Milestone]] -- [[Dependencies]] -- [[Capacity]] -- [[Risk]] -- [[Project Health]] -- [[Portfolio Management]] +- \[\[Milestones vs Tasks\]\] +- \[\[Dependencies\]\] +- \[\[Estimation and Forecasting\]\] +- \[\[Prioritization\]\] +- \[[Capacity and WIP](#capacity-and-wip)\] +- \[\[Risk Management\]\] +- \[\[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 index 020e836..46d6c6d 100644 --- a/10 Knowledge/CTO Academy/Project Management/Closing Projects.md +++ b/10 Knowledge/CTO Academy/Project Management/Closing Projects.md @@ -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. -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. +### Outcome / DoD + +- Was the intended outcome achieved? +- 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. - -The objective is to move from theory to a repeatable management practice. +QA automation reaches its agreed DoD. Product asks for five more +automated scenarios. If they were not required for the outcome, put them +in backlog or Phase 2 and close the original project. ## 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. +Lesson 1 established that projects are temporary. Lesson 2 created +Definition of Done. Closure is where those ideas are enforced and the +project transitions to operations where necessary. ## 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: - -- 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. +Every successful project can therefore add operational load. That new +load affects future project capacity and should be visible. ## 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: - -```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 -``` +Closure is not paperwork. It confirms the organization can safely live +with what was delivered. ### 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? +- Has the outcome been achieved? +- Does the DoD pass? +- Who accepts it? +- Who owns it after closure? +- 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:** - -A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. +**Situation:** Development and QA are complete, but nice-to-have +improvements keep the project open indefinitely. **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. -- 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. +- Closure validates outcome and DoD. +- Development completion alone does not close a project. +- Operational ownership must be explicit. +- Enhancements do not necessarily block closure. +- Closure removes unnecessary project overhead. +- Every completed project may create new operational load. ## Related Concepts -- [[Projects vs Operations]] -- [[Project Outcome]] -- [[Definition of Done]] -- [[Scope]] -- [[Milestone]] -- [[Dependencies]] -- [[Capacity]] -- [[Risk]] -- [[Project Health]] -- [[Portfolio Management]] +- [[Projects vs Operations]] +- [[Outcomes and Definition of Done]] +- [[Scope and Scope Creep]] +- [[Capacity and WIP]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Dependencies.md b/10 Knowledge/CTO Academy/Project Management/Dependencies.md index a92246d..9f274e9 100644 --- a/10 Knowledge/CTO Academy/Project Management/Dependencies.md +++ b/10 Knowledge/CTO Academy/Project Management/Dependencies.md @@ -1,101 +1,107 @@ -Duration: 30–40 minutes +Duration: 30--40 minutes ## Definition -Identify work, people, teams, vendors, and decisions that can block delivery. - -This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. +A dependency is something a project needs but does not fully control. It +may be another task, person, team, vendor, environment, approval, +decision, data source, or access requirement. A blocker is a dependency +that is currently preventing progress. ## Simple Mental Model -The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage. +**What must happen outside this work before we can reach the next +milestone?** ## How It Works -We will examine this concept through four levels: +Project owners should identify dependencies early, record who owns them +and when they are needed, follow up before they become blockers, and +escalate when authority or priority is required. -1. What the concept means. -2. How a project owner should use it. -3. How you should review or challenge it as the manager. -4. How it should eventually appear in your project-management system. +### Dependency types -## Example +- Internal: another task or contributor inside the project +- Cross-team: Product, DevOps, Security, IT, Finance, etc. +- External: vendor, partner, contractor +- Decision: approval or choice required before work can proceed -The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security. +A dependency is not automatically a risk. "DevOps must create the +environment" is a dependency. "DevOps may not have capacity by August +15" is a risk. -The objective is to move from theory to a repeatable management practice. +### Example -## How It Fits Into the Bigger Picture +For an analytics implementation: -The course builds progressively: + ----------------------------------------------------------------------- + Dependency Owner Needed by Impact if late + ----------------- ----------------- ----------------- ----------------- + Production DevOps Aug 15 QA cannot start + environment -- Project vs operations establishes what kind of work we are managing. -- Outcomes and Definition of Done establish what success means. -- Scope establishes the project's boundaries. -- Milestones establish meaningful progress. -- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable. -- Status reporting, meetings, ownership, and portfolio management make the system scalable. -- Closing and the final PM system turn the concepts into an operating method. + Security review Security Aug 20 Production + blocked -## My Company / Real-World Context + Tracking Product/Data Aug 5 Implementation + requirements unclear + ----------------------------------------------------------------------- -Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security. +In your environment this matters because project owners frequently +depend on Product, DevOps, Security, vendors, QA, and other departments. +The owner may not control those teams, but still owns making the +dependency visible and following it. -The lesson should therefore be applied to an environment where: +### CTO Perspective -- Project owners are usually members of your own team rather than dedicated PMs. -- Operational work regularly interrupts project work. -- Product and IT are important cross-functional partners. -- You need portfolio-level visibility without personally maintaining every task. -- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate. - -## CTO Perspective - -The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes. - -The expected progression is: - -```text -Contributor → manages tasks -Project Owner → drives milestones and delivery -Manager → manages projects, priorities, risks and escalation -Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs -``` +You should not personally chase every dependency. The owner manages +normal follow-up. You intervene when priorities conflict, a committed +milestone is threatened, the owner lacks authority, or the same +bottleneck repeatedly affects projects. ### Questions to Ask -- What information do I need to make a management decision? -- What should the project owner be responsible for maintaining? -- What requires my intervention? -- What can be standardized across every project? -- Is the process helping delivery, or merely creating administration? +- What does the next milestone depend on? +- Who owns it? +- When is it needed? +- Has the other team actually committed? +- What happens if it is late? +- When should this be escalated? -## Meeting Scenario +### Meeting Scenario -**Situation:** - -A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. +**Situation:** The owner says Friday's milestone will slip because +DevOps has not created the environment. **Possible response:** -> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me. +> When did we identify the dependency, what date did DevOps commit to, +> and when did we know it was at risk? If you've already followed up and +> the milestone is threatened, I'll help escalate it. -## Key Takeaways +### Key Takeaways -- The purpose of project management is predictable delivery, not documentation for its own sake. -- Project owners should own increasingly more of the planning and maintenance. -- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio. -- Every concept learned should eventually contribute to one lightweight common project template. -- The final system should make exceptions and problems visible without requiring you to inspect every task. +- Dependencies are things the project needs but does not fully + control. +- Blockers are dependencies actively preventing progress. +- Identify dependencies from milestones before they are needed. +- Project owners manage routine follow-up. +- Managers handle cross-team priority and authority escalation. +- Repeated dependency failures may reveal an organizational + bottleneck. + +## How It Fits Into the Bigger Picture + +This lesson builds on [[Projects vs Operations]], [[Outcomes and +Definition of Done]], [[Scope and Scope Creep]], and +[[Milestones vs Tasks]]. It prepares the project system to become +more predictable and scalable. ## Related Concepts -- [[Projects vs Operations]] -- [[Outcomes and Definition of Done]] -- [[Scope and Scope Creep]] -- [[Milestones vs Tasks]] -- [[Dependencies]] -- [[Capacity and WIP]] -- [[Risk Management]] -- [[Project Health]] -- [[Portfolio Management]] +- [[Milestones vs Tasks]] +- [[Estimation and Forecasting]] +- [[Prioritization]] +- [[Capacity and WIP]] +- [[Risk Management]] +- [[Project Health]] +- [[Portfolio Management]] diff --git a/10 Knowledge/CTO Academy/Project Management/Estimation and Forecasting.md b/10 Knowledge/CTO Academy/Project Management/Estimation and Forecasting.md index 8612e70..f13160d 100644 --- a/10 Knowledge/CTO Academy/Project Management/Estimation and Forecasting.md +++ b/10 Knowledge/CTO Academy/Project Management/Estimation and Forecasting.md @@ -1,102 +1,105 @@ -Duration: 30–40 minutes +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. +Estimation predicts the effort or time required for work. Forecasting +combines estimates with capacity, dependencies, uncertainty, and current +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. -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. +Estimate milestone by milestone after outcome, scope, and major +dependencies are understood. Then account for real constraints. -## 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 +``` text +Requirements 1 week +Implementation 3 weeks +QA 1 week +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 should the project owner be responsible for maintaining? -- What requires my intervention? -- What can be standardized across every project? -- Is the process helping delivery, or merely creating administration? +- What is the estimate based on? +- Which milestone has the most uncertainty? +- What assumptions are we making? +- What capacity is actually available? +- 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:** - -> 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. +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]] -- [[Project Outcome]] -- [[Definition of Done]] -- [[Scope]] -- [[Milestone]] -- [[Dependencies]] -- [[Capacity]] -- [[Risk]] -- [[Project Health]] -- [[Portfolio Management]] +- [[Milestones vs Tasks]] +- [[Dependencies]] +- [[Prioritization]] +- [[Capacity and WIP]] +- [[Risk Management]] +- [[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 index f50e291..8a755cc 100644 --- a/10 Knowledge/CTO Academy/Project Management/Meetings and Follow-up.md +++ b/10 Knowledge/CTO Academy/Project Management/Meetings and Follow-up.md @@ -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. -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. +A useful review agenda: + +1. Outcome / health +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. - -The objective is to move from theory to a repeatable management practice. +A weekly 60-minute meeting with eight people mostly consists of everyone +describing what they did. Replace the reporting portion asynchronously +and use synchronous time for two blockers and one scope decision. ## 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. +Status reporting communicates project state. Meetings resolve what +cannot efficiently be resolved asynchronously. \[\[Ownership and +Delegation\]\] determines who follows through afterward. ## 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. +Cross-functional work with Product, DevOps, Security, IT, and vendors +can create meeting overload. Your project owner should drive normal +project follow-up. You join when your authority, escalation, or judgment +is required. ## 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 -``` +If every project requires you in every meeting, **you are the system**. +A scalable leader designs ownership and information flow so their +presence is needed only where it adds value. ### 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? +- Does this require a meeting? +- What decision must be made? +- Who actually needs to attend? +- What is blocked? +- Who owns each action? +- By when? +- Can the owner follow this without me? ## Meeting Scenario -**Situation:** - -A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. +**Situation:** An owner includes you in a weekly execution meeting where +most discussion is detailed implementation. **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. -- 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. +- Meetings are tools, not evidence of progress. +- Use synchronous time for decisions, blockers, and coordination. +- Actions need owners and dates. +- Capture decisions separately. +- Prefer asynchronous status where possible. +- Project owners should drive normal follow-up. ## Related Concepts -- [[Projects vs Operations]] -- [[Project Outcome]] -- [[Definition of Done]] -- [[Scope]] -- [[Milestone]] -- [[Dependencies]] -- [[Capacity]] -- [[Risk]] -- [[Project Health]] -- [[Portfolio Management]] +- \[\[Status Reporting\]\] +- \[\[Ownership and Delegation\]\] +- \[\[Decision Log\]\] +- \[\[Project Health\]\] diff --git a/10 Knowledge/CTO Academy/Project Management/Ownership and Delegation.md b/10 Knowledge/CTO Academy/Project Management/Ownership and Delegation.md index 5462ccb..feeb519 100644 --- a/10 Knowledge/CTO Academy/Project Management/Ownership and Delegation.md +++ b/10 Knowledge/CTO Academy/Project Management/Ownership and Delegation.md @@ -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. -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. +- Draft the project brief +- Clarify outcome and DoD +- Propose scope and milestones +- 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. -- 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. +> Amadou manages every project + +to: + +> Amadou manages a system in which people can own projects. ## 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 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. +Project ownership also develops employees beyond ticket execution. ## 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 -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 -``` +> I know the portfolio and intervene where needed. + +not: + +> Nothing moves unless I chase it. ### 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? +- Who is the single owner? +- What can they decide without me? +- What must come back to me? +- Are they maintaining the project or am I? +- Are they escalating early? +- Am I coaching or taking the project back? +- Does accountability match authority? ## Meeting Scenario -**Situation:** - -A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. +**Situation:** An owner finds a Product request that changes scope and +immediately asks you what to do. **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. -- 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. +- Every project needs one clearly accountable owner. +- Owners drive outcomes; they do not perform every task. +- Owners should draft and maintain the project brief. +- Managers validate, challenge, coach, prioritize, and escalate. +- Delegation increases with capability. +- Accountability must match authority. +- Developing owners makes the system scalable. ## Related Concepts -- [[Projects vs Operations]] -- [[Project Outcome]] -- [[Definition of Done]] -- [[Scope]] -- [[Milestone]] -- [[Dependencies]] -- [[Capacity]] -- [[Risk]] -- [[Project Health]] -- [[Portfolio Management]] +- \[\[Portfolio Management\]\] +- \[\[Meetings and Follow-up\]\] +- \[\[Status Reporting\]\] +- \[\[Project Health\]\] diff --git a/10 Knowledge/CTO Academy/Project Management/Portfolio Management.md b/10 Knowledge/CTO Academy/Project Management/Portfolio Management.md index b968805..c6fd2ff 100644 --- a/10 Knowledge/CTO Academy/Project Management/Portfolio Management.md +++ b/10 Knowledge/CTO Academy/Project Management/Portfolio Management.md @@ -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. -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. +- What is active? +- What is queued? +- What is on hold? +- 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: - -- 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. +\[\[Prioritization\]\] decides relative importance. \[\[Capacity and +WIP\]\] determines how much can be active. \[\[Project Health\]\] +identifies where intervention is needed. Portfolio management combines +them. ## 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. -- 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. +> **What needs my attention?** + +rather than merely: + +> 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: - -```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 -``` +> **Every project approval is a resource-allocation decision.** ### 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? +- Why are we doing this? +- What is its priority relative to others? +- Do we have capacity to start? +- What will it displace? +- 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:** - -A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. +**Situation:** Leadership approves another initiative and asks when your +team can begin. **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. -- 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. +- Portfolio management manages projects as a competing collection. +- Approved does not mean active. +- Queued and on-hold states are healthy. +- Portfolio views focus on management information, not task detail. +- Priority, capacity, WIP, and health come together here. +- Starting new work should expose what it displaces. ## Related Concepts -- [[Projects vs Operations]] -- [[Project Outcome]] -- [[Definition of Done]] -- [[Scope]] -- [[Milestone]] -- [[Dependencies]] -- [[Capacity]] -- [[Risk]] -- [[Project Health]] -- [[Portfolio Management]] +- \[\[Prioritization\]\] +- \[\[Capacity and WIP\]\] +- \[\[Project Health\]\] +- \[\[Status Reporting\]\] +- \[\[Ownership and Delegation\]\] diff --git a/10 Knowledge/CTO Academy/Project Management/Prioritization.md b/10 Knowledge/CTO Academy/Project Management/Prioritization.md index 1f85915..1d477c5 100644 --- a/10 Knowledge/CTO Academy/Project Management/Prioritization.md +++ b/10 Knowledge/CTO Academy/Project Management/Prioritization.md @@ -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. - -This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. +Prioritization is the deliberate decision about which work receives +scarce capacity first. A priority is meaningful only if it changes what +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. -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. +Useful factors include business value, urgency, risk reduction, fixed +deadlines, strategic alignment, dependencies, effort, and cost of delay. -## 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 -Project Owner → drives milestones and delivery -Manager → manages projects, priorities, risks and escalation -Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs +``` text +1. Production incident +2. Supabase migration +3. Umami +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 should the project owner be responsible for maintaining? -- What requires my intervention? -- What can be standardized across every project? -- Is the process helping delivery, or merely creating administration? +- What happens if we do not do this now? +- Is there a fixed deadline? +- What business outcome does it support? +- What does it unblock? +- 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:** - -> 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. +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]] -- [[Project Outcome]] -- [[Definition of Done]] -- [[Scope]] -- [[Milestone]] -- [[Dependencies]] -- [[Capacity]] -- [[Risk]] -- [[Project Health]] -- [[Portfolio Management]] +- \[\[Milestones vs Tasks\]\] +- \[\[Dependencies\]\] +- \[\[Estimation and Forecasting\]\] +- \[[Prioritization](#prioritization)\] +- \[\[Capacity and WIP\]\] +- \[\[Risk Management\]\] +- \[\[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 index 4b1f363..a620847 100644 --- a/10 Knowledge/CTO Academy/Project Management/Project Health.md +++ b/10 Knowledge/CTO Academy/Project Management/Project Health.md @@ -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. -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. +- Next milestone and target +- Current forecast +- Scope stability +- 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: - -- 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. +Milestones provide checkpoints. Dependencies and risks explain threats. +Forecasting predicts delivery. Health compresses those signals into a +portfolio-level indicator. ## 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. -- 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. +Then you focus your attention on Yellow and Red rather than opening +every project. ## 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: - -```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 -``` +If owners keep projects Green until failure is undeniable, the system is +useless. Make early Yellow reporting useful rather than treating it as +failure. ### Questions to Ask -- What information do I need to make a management decision? -- What should the project owner be responsible for maintaining? -- What requires my intervention? -- What can be standardized across every project? -- Is the process helping delivery, or merely creating administration? +- What is the next milestone? +- Is the forecast still credible? +- What is the biggest risk? +- Is scope stable? +- Are dependencies committed? +- What specifically would return Yellow to Green? +- Does this need my intervention? ## Meeting Scenario -**Situation:** - -A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. +**Situation:** A project owner reports Green because no deadline has +been missed, but a critical vendor deliverable has no confirmed date. **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. -- 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. +- Health is forward-looking. +- Green/Yellow/Red need shared definitions. +- Yellow is an early-warning state. +- Percent complete is not project health. +- Health should reflect milestones, risks, dependencies, scope, and + forecast. +- Reliable health enables management by exception. ## Related Concepts -- [[Projects vs Operations]] -- [[Project Outcome]] -- [[Definition of Done]] -- [[Scope]] -- [[Milestone]] -- [[Dependencies]] -- [[Capacity]] -- [[Risk]] -- [[Project Health]] -- [[Portfolio Management]] +- \[\[Milestones vs Tasks\]\] +- \[\[Risk Management\]\] +- \[\[Dependencies\]\] +- \[\[Status Reporting\]\] +- \[\[Portfolio Management\]\] diff --git a/10 Knowledge/CTO Academy/Project Management/Risk Management.md b/10 Knowledge/CTO Academy/Project Management/Risk Management.md index 6b47334..13c73d2 100644 --- a/10 Knowledge/CTO Academy/Project Management/Risk Management.md +++ b/10 Knowledge/CTO Academy/Project Management/Risk Management.md @@ -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. - -This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons. +A **risk** is an uncertain event or condition that could affect the +project's outcome, schedule, scope, quality, cost, or operations. An +**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. -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. +1. **Identify** what could prevent the outcome or next milestone. +2. **Assess** probability and impact. +3. **Respond** by avoiding, mitigating, transferring/sharing, or + 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. - -The objective is to move from theory to a repeatable management practice. +Your project is on schedule, but Security has not reviewed an +architecture required for production. The deadline has not slipped yet, +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: - -- 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. +Dependencies tell you what the project needs. Estimation exposes +assumptions. Risk management asks what could make those assumptions +fail. \[\[Project Health\]\] then reflects important risks before +deadlines are actually missed. ## 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: - -- 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. +Focus on the few risks capable of materially changing delivery rather +than maintaining a huge register nobody reads. ## 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 -``` +A project should not remain Green merely because nothing bad has +happened yet. Leadership status must be forward-looking. ### Questions to Ask -- What information do I need to make a management decision? -- What should the project owner be responsible for maintaining? -- What requires my intervention? -- What can be standardized across every project? -- Is the process helping delivery, or merely creating administration? +- What could prevent the next milestone? +- What assumptions are we relying on? +- Which risk has the highest impact? +- Who owns the response? +- What can we do now? +- What signal tells us the risk is becoming an issue? +- Does this risk change project health? ## Meeting Scenario -**Situation:** - -A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. +**Situation:** Security has not reviewed a required architecture and +production is approaching. **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. -- 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. +- Risks are uncertain future events; issues are current problems. +- Identify risks before they become blockers. +- Focus on material risks. +- Assess probability and impact. +- Significant risks need an owner and response. +- Health should reflect major risks before a deadline is missed. ## Related Concepts -- [[Projects vs Operations]] -- [[Project Outcome]] -- [[Definition of Done]] -- [[Scope]] -- [[Milestone]] -- [[Dependencies]] -- [[Capacity]] -- [[Risk]] -- [[Project Health]] -- [[Portfolio Management]] +- \[\[Dependencies\]\] +- \[\[Project Health\]\] +- \[\[Estimation and Forecasting\]\] +- \[\[Capacity and WIP\]\] +- \[\[RAID\]\] diff --git a/10 Knowledge/CTO Academy/Project Management/Status Reporting.md b/10 Knowledge/CTO Academy/Project Management/Status Reporting.md index b17f956..5a8d292 100644 --- a/10 Knowledge/CTO Academy/Project Management/Status Reporting.md +++ b/10 Knowledge/CTO Academy/Project Management/Status Reporting.md @@ -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. -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. +``` text +Health: +Outcome: +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 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. +\[\[Project Health\]\] tells you whether attention is required. Status +reporting explains why, what changed, and what action is needed. ## 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: - -- 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. +Instead of "the sync API returns errors," say what that means for the +milestone and outcome. ## 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: - -```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 -``` +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 +it. ### Questions to Ask -- What information do I need to make a management decision? -- What should the project owner be responsible for maintaining? -- What requires my intervention? -- What can be standardized across every project? -- Is the process helping delivery, or merely creating administration? +- What changed? +- What is the health? +- What is the next milestone? +- Is the forecast credible? +- What is the main risk/blocker? +- What is the consequence? +- What decision/help is required? ## Meeting Scenario -**Situation:** - -A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome. +**Situation:** Your VP asks for an update on a project with a vendor +blocker. **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. -- 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. +- Report delivery, not activity. +- Tailor detail to the audience. +- Lead with health and outcome. +- Explain consequences. +- State decisions/help required. +- Early transparent reporting builds trust. ## Related Concepts -- [[Projects vs Operations]] -- [[Project Outcome]] -- [[Definition of Done]] -- [[Scope]] -- [[Milestone]] -- [[Dependencies]] -- [[Capacity]] -- [[Risk]] -- [[Project Health]] -- [[Portfolio Management]] +- \[\[Project Health\]\] +- \[\[Milestones vs Tasks\]\] +- \[\[Risk Management\]\] +- \[\[Portfolio Management\]\]