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

2026-07-23 14:57:54 +02:00
parent 0527e561b3
commit 8526cf4212
12 changed files with 1084 additions and 799 deletions
@@ -1,103 +1,134 @@
 # Ownership and Delegation
-Duration: 30–40 minutes
+
+Duration: 30--40 minutes

 ## Definition

-Make project ownership clear and develop team members who can drive projects.
+**Project ownership** means one person is accountable for driving a
+project toward its agreed outcome. The owner does not need to perform
+every task.

-This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
+**Delegation** transfers responsibility and appropriate authority while
+keeping enough management visibility to ensure the outcome.

 ## 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.
+> **One project, one clearly accountable owner.**
+
+The owner manages the project. You manage the owner, priorities,
+escalation, and portfolio.

 ## How It Works

-We will examine this concept through four levels:
+A project owner should increasingly:

-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.
+-   Draft the project brief
+-   Clarify outcome and DoD
+-   Propose scope and milestones
+-   Identify dependencies and risks
+-   Coordinate contributors
+-   Maintain status
+-   Surface scope changes
+-   Escalate blockers
+-   Drive closure
+
+Your role:
+
+-   Approve and prioritize
+-   Challenge the plan
+-   Confirm commitments
+-   Coach
+-   Resolve priority/authority conflicts
+-   Escalate organizational blockers
+-   Review outcomes
+
+Delegation can increase progressively:
+
+1.  Research and report
+2.  Recommend a plan
+3.  Act after approval
+4.  Act and inform
+5.  Own the outcome within agreed boundaries
+
+Accountability must come with enough authority to coordinate and
+escalate.

 ## 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.
+Instead of writing the Umami plan yourself:

-The objective is to move from theory to a repeatable management practice.
+> Draft the outcome, DoD, scope, milestones, dependencies, risks, and
+> proposed forecast. We'll review it together Friday.
+
+The owner proposes eight weeks. You challenge assumptions and agree on a
+commitment. They maintain the project afterward.

 ## How It Fits Into the Bigger Picture

-The course builds progressively:
+Everything learned so far becomes information the project owner manages.
+This is the transition from:

- 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.
+> Amadou manages every project
+
+to:
+
+> Amadou manages a system in which people can own projects.

 ## 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.
+You do not have a PMO assigning PMs to your work. Integrators, analysts,
+QA, or other team members can own projects depending on capability and
+subject matter.

-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.
+Project ownership also develops employees beyond ticket execution.

 ## CTO Perspective

-The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes.
+Broader technology leadership requires an organization that can operate
+without you personally coordinating everything.

-The expected progression is:
+The goal 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
-```
+> I know the portfolio and intervene where needed.
+
+not:
+
+> Nothing moves unless I chase it.

 ### 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?
+-   Who is the single owner?
+-   What can they decide without me?
+-   What must come back to me?
+-   Are they maintaining the project or am I?
+-   Are they escalating early?
+-   Am I coaching or taking the project back?
+-   Does accountability match authority?

 ## 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:** An owner finds a Product request that changes scope and
+immediately asks you what to do.

 **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.
+> You've identified the scope change correctly. Before I decide, tell me
+> the impact on the milestone and what options you recommend. Bring me
+> the trade-off, not only the problem.

 ## 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.
+-   Every project needs one clearly accountable owner.
+-   Owners drive outcomes; they do not perform every task.
+-   Owners should draft and maintain the project brief.
+-   Managers validate, challenge, coach, prioritize, and escalate.
+-   Delegation increases with capability.
+-   Accountability must match authority.
+-   Developing owners makes the system scalable.

 ## Related Concepts

- [[Projects vs Operations]]
- [[Project Outcome]]
- [[Definition of Done]]
- [[Scope]]
- [[Milestone]]
- [[Dependencies]]
- [[Capacity]]
- [[Risk]]
- [[Project Health]]
- [[Portfolio Management]]
+-   \[\[Portfolio Management\]\]
+-   \[\[Meetings and Follow-up\]\]
+-   \[\[Status Reporting\]\]
+-   \[\[Project Health\]\]