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

This commit is contained in:
2026-07-23 14:57:54 +02:00
parent 0527e561b3
commit 8526cf4212
12 changed files with 1084 additions and 799 deletions
@@ -1,103 +1,136 @@
# Portfolio Management
Duration: 3040 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\]\]