271 lines
6.1 KiB
Markdown
271 lines
6.1 KiB
Markdown
# Building My PM System
|
|
|
|
Duration: 30--40 minutes
|
|
|
|
## Definition
|
|
|
|
A **project management system** is the repeatable set of roles,
|
|
information, routines, and tools used to move work from proposal to
|
|
completion.
|
|
|
|
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 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
|
|
|
|
### 1. Standard Project Brief
|
|
|
|
``` 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
|
|
|
|
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
|
|
|
|
You inspect Mogador first, then Umami. The system tells you where
|
|
management attention is required.
|
|
|
|
## How It Fits Into the Bigger Picture
|
|
|
|
``` 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 original problem was that Monday contained projects and timelines,
|
|
but you rarely returned to update it.
|
|
|
|
The answer is not simply that you need to remember Monday more.
|
|
|
|
> **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
|
|
|
|
This is the transition from personal competence to management
|
|
capability.
|
|
|
|
The test is not:
|
|
|
|
> 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
|
|
|
|
- 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:** You open Monday after two weeks and several projects are
|
|
stale because you are still expected to update everything.
|
|
|
|
**Possible response:**
|
|
|
|
> 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
|
|
|
|
- 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\]\]
|
|
- \[\[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\]\]
|