114 lines
3.0 KiB
Markdown
114 lines
3.0 KiB
Markdown
Duration: 30--40 minutes
|
|
|
|
## Definition
|
|
|
|
**Project health** is a concise assessment of whether a project is
|
|
likely to achieve its agreed outcome within its current commitments.
|
|
|
|
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
|
|
|
|
> **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
|
|
|
|
Health should consider:
|
|
|
|
- Next milestone and target
|
|
- Current forecast
|
|
- Scope stability
|
|
- Dependencies
|
|
- Risks/issues
|
|
- Capacity
|
|
- Quality/acceptance
|
|
- Decisions required
|
|
|
|
Yellow should be an early-warning state, not a punishment.
|
|
|
|
Example:
|
|
|
|
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
|
|
|
|
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 Monday board currently shows execution status, but your management
|
|
need is closer to:
|
|
|
|
``` text
|
|
Umami Yellow
|
|
Supabase Green
|
|
Mogador Red
|
|
QA Automation Green
|
|
Data Governance Yellow
|
|
```
|
|
|
|
Then you focus your attention on Yellow and Red rather than opening
|
|
every project.
|
|
|
|
## CTO Perspective
|
|
|
|
Health indicators enable **management by exception**. But the colors
|
|
must be trustworthy.
|
|
|
|
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 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 reports Green because no deadline has
|
|
been missed, but a critical vendor deliverable has no confirmed date.
|
|
|
|
**Possible response:**
|
|
|
|
> 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
|
|
|
|
- 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
|
|
|
|
- [[Milestones vs Tasks]]
|
|
- [[Risk Management]]
|
|
- [[Dependencies]]
|
|
- [[Status Reporting]]
|
|
- [[Portfolio Management]]
|