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/Closing Projects.md
+81 -63
View File
@@ -1,103 +1,121 @@
# Closing Projects
Duration: 30–40 minutes
Duration: 30--40 minutes
## Definition
Formally accept outcomes, hand work to operations, document lessons, and close projects.
**Project closure** confirms that the agreed outcome and Definition of
Done are satisfied, ongoing responsibilities are handed off, and the
project can leave the active portfolio.
This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
A project is not closed simply because development stopped.
## 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.
> **Done → accepted → handed off → closed.**
## How It Works
We will examine this concept through four levels:
Before closure verify:
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.
### Outcome / DoD
- Was the intended outcome achieved?
- Are mandatory DoD criteria satisfied?
- Has the right stakeholder accepted it?
### Handoff
- Who owns it operationally?
- Is monitoring in place?
- Is documentation sufficient?
- Are support responsibilities clear?
- Are access/credentials transferred where relevant?
### Remaining work
Separate:
- Required for DoD
- Defect that blocks acceptance
- Enhancement/backlog item
- Future Phase 2
Not every improvement needs to keep the project open.
### Lessons learned
Keep it lightweight:
- What worked?
- What caused delay?
- What should we repeat?
- What should change next time?
## 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.
The objective is to move from theory to a repeatable management practice.
QA automation reaches its agreed DoD. Product asks for five more
automated scenarios. If they were not required for the outcome, put them
in backlog or Phase 2 and close the original project.
## 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.
Lesson 1 established that projects are temporary. Lesson 2 created
Definition of Done. Closure is where those ideas are enforced and the
project transitions to operations where necessary.
## 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.
Monitoring systems, analytics platforms, synchronization processes, QA
automation, and website capabilities all create ongoing
responsibilities.
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.
Every successful project can therefore add operational load. That new
load affects future project capacity and should be visible.
## CTO Perspective
The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes.
A project that launches without an operational owner, monitoring,
documentation, or support model may simply transfer risk into the
organization.
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
```
Closure is not paperwork. It confirms the organization can safely live
with what was delivered.
### 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?
- Has the outcome been achieved?
- Does the DoD pass?
- Who accepts it?
- Who owns it after closure?
- What operational load does it create?
- Are remaining items blockers or enhancements?
- What did we learn?
- Can it leave the active portfolio?
## 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:** Development and QA are complete, but nice-to-have
improvements keep the project open indefinitely.
**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.
> Let's compare the remaining items to the agreed Definition of Done. If
> the outcome is achieved and these are enhancements, we'll close the
> project and move them into backlog or Phase 2.
## 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.
- Closure validates outcome and DoD.
- Development completion alone does not close a project.
- Operational ownership must be explicit.
- Enhancements do not necessarily block closure.
- Closure removes unnecessary project overhead.
- Every completed project may create new operational load.
## 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]]
- [[Capacity and WIP]]
- [[Portfolio Management]]