122 lines
3.2 KiB
Markdown
122 lines
3.2 KiB
Markdown
|
|
Duration: 30--40 minutes
|
|
|
|
## Definition
|
|
|
|
**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.
|
|
|
|
A project is not closed simply because development stopped.
|
|
|
|
## Simple Mental Model
|
|
|
|
> **Done → accepted → handed off → closed.**
|
|
|
|
## How It Works
|
|
|
|
Before closure verify:
|
|
|
|
### 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
|
|
|
|
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
|
|
|
|
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
|
|
|
|
Monitoring systems, analytics platforms, synchronization processes, QA
|
|
automation, and website capabilities all create ongoing
|
|
responsibilities.
|
|
|
|
Every successful project can therefore add operational load. That new
|
|
load affects future project capacity and should be visible.
|
|
|
|
## CTO Perspective
|
|
|
|
A project that launches without an operational owner, monitoring,
|
|
documentation, or support model may simply transfer risk into the
|
|
organization.
|
|
|
|
Closure is not paperwork. It confirms the organization can safely live
|
|
with what was delivered.
|
|
|
|
### Questions to Ask
|
|
|
|
- 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:** Development and QA are complete, but nice-to-have
|
|
improvements keep the project open indefinitely.
|
|
|
|
**Possible response:**
|
|
|
|
> 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
|
|
|
|
- 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]]
|
|
- [[Outcomes and Definition of Done]]
|
|
- [[Scope and Scope Creep]]
|
|
- [[Capacity and WIP]]
|
|
- [[Portfolio Management]]
|