104 lines
4.0 KiB
Markdown
104 lines
4.0 KiB
Markdown
# Project Health
|
||
Duration: 30–40 minutes
|
||
|
||
## Definition
|
||
|
||
Use evidence to classify projects as healthy, at risk, or off track.
|
||
|
||
This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
|
||
|
||
## Simple Mental Model
|
||
|
||
The goal is not to add project-management bureaucracy. The goal is to make the project easier to understand, predict, and manage.
|
||
|
||
## How It Works
|
||
|
||
We will examine this concept through four levels:
|
||
|
||
1. What the concept means.
|
||
2. How a project owner should use it.
|
||
3. How you should review or challenge it as the manager.
|
||
4. How it should eventually appear in your project-management system.
|
||
|
||
## Example
|
||
|
||
The exercises for this lesson should use real projects from your environment such as Umami, Mogador, QA automation, data governance, website/Product initiatives, or projects dependent on DevOps and Security.
|
||
|
||
The objective is to move from theory to a repeatable management practice.
|
||
|
||
## How It Fits Into the Bigger Picture
|
||
|
||
The course builds progressively:
|
||
|
||
- Project vs operations establishes what kind of work we are managing.
|
||
- Outcomes and Definition of Done establish what success means.
|
||
- Scope establishes the project's boundaries.
|
||
- Milestones establish meaningful progress.
|
||
- Dependencies, estimation, prioritization, capacity, risks, and health make delivery more predictable.
|
||
- Status reporting, meetings, ownership, and portfolio management make the system scalable.
|
||
- Closing and the final PM system turn the concepts into an operating method.
|
||
|
||
## My Company / Real-World Context
|
||
|
||
Your team works across departmental projects, Product work, operational incidents, tickets, data, QA, SEO/WCAG, and dependencies on IT teams such as DevOps and Security.
|
||
|
||
The lesson should therefore be applied to an environment where:
|
||
|
||
- Project owners are usually members of your own team rather than dedicated PMs.
|
||
- Operational work regularly interrupts project work.
|
||
- Product and IT are important cross-functional partners.
|
||
- You need portfolio-level visibility without personally maintaining every task.
|
||
- Project owners should increasingly draft and maintain their own project plans while you validate, challenge, prioritize, and escalate.
|
||
|
||
## CTO Perspective
|
||
|
||
The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes.
|
||
|
||
The expected progression is:
|
||
|
||
```text
|
||
Contributor → manages tasks
|
||
Project Owner → drives milestones and delivery
|
||
Manager → manages projects, priorities, risks and escalation
|
||
Technology Leader → manages portfolio, capacity, outcomes and organizational trade-offs
|
||
```
|
||
|
||
### Questions to Ask
|
||
|
||
- What information do I need to make a management decision?
|
||
- What should the project owner be responsible for maintaining?
|
||
- What requires my intervention?
|
||
- What can be standardized across every project?
|
||
- Is the process helping delivery, or merely creating administration?
|
||
|
||
## Meeting Scenario
|
||
|
||
**Situation:**
|
||
|
||
A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome.
|
||
|
||
**Possible response:**
|
||
|
||
> Let's bring this back to the project plan. Show me where we are against the next meaningful checkpoint, what is at risk, and what decision or help you need from me.
|
||
|
||
## Key Takeaways
|
||
|
||
- The purpose of project management is predictable delivery, not documentation for its own sake.
|
||
- Project owners should own increasingly more of the planning and maintenance.
|
||
- Your role is to challenge assumptions, establish priorities, remove/escalate blockers, and manage the portfolio.
|
||
- Every concept learned should eventually contribute to one lightweight common project template.
|
||
- The final system should make exceptions and problems visible without requiring you to inspect every task.
|
||
|
||
## Related Concepts
|
||
|
||
- [[Projects vs Operations]]
|
||
- [[Project Outcome]]
|
||
- [[Definition of Done]]
|
||
- [[Scope]]
|
||
- [[Milestone]]
|
||
- [[Dependencies]]
|
||
- [[Capacity]]
|
||
- [[Risk]]
|
||
- [[Project Health]]
|
||
- [[Portfolio Management]]
|