vault backup: 2026-07-23 14:57:54
This commit is contained in:
@@ -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\]\]
|
||||
|
||||
@@ -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\]\]
|
||||
|
||||
@@ -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]]
|
||||
|
||||
@@ -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]]
|
||||
|
||||
@@ -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]]
|
||||
|
||||
@@ -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\]\]
|
||||
|
||||
@@ -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\]\]
|
||||
|
||||
@@ -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\]\]
|
||||
|
||||
@@ -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\]\]
|
||||
|
||||
@@ -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\]\]
|
||||
|
||||
@@ -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\]\]
|
||||
|
||||
@@ -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\]\]
|
||||
|
||||
Reference in New Issue
Block a user