amadou/SecondBrain
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2026-07-23 14:57:54

Browse Source
This commit is contained in:
amadou
2026-07-23 14:57:54 +02:00
parent 0527e561b3
commit 8526cf4212
12 changed files with 1084 additions and 799 deletions
Download Patch File Download Diff File Expand all files Collapse all files
10 Knowledge/CTO Academy/Project Management/Building My PM System.md
+226 -59
View File
@@ -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\]\]