vault backup: 2026-07-23 10:53:54

2026-07-23 10:53:54 +02:00
parent b0fbd99b92
commit e927fe12c4
1 changed files with 558 additions and 0 deletions
@@ -0,0 +1,558 @@
+Duration: 30–35 minutes
+
+## Definition
+
+A project should not be defined primarily by **what the team will do**.
+
+It should be defined by **what will be different when the project succeeds**.
+
+This introduces two closely related concepts:
+
+### Outcome
+
+An **outcome** describes the result or change the project is intended to produce.
+
+It answers:
+
+> **What are we trying to achieve?**
+
+### Definition of Done
+
+The **Definition of Done** describes the conditions that must be true before we can legitimately say the project is complete.
+
+It answers:
+
+> **How will we know we're finished?**
+
+These sound simple, but poorly defined outcomes are one of the reasons projects become difficult to manage.
+
+---
+
+## Simple Mental Model
+
+Think:
+
+> **Outcome = destination.**  
+> **Definition of Done = evidence that we've arrived.**
+
+"Implement Umami" tells me what you're doing.
+
+"Reliable website analytics are collected independently of GA4 and available for internal analysis" tells me **why the project exists and what should be different afterward**.
+
+The Definition of Done then makes that outcome concrete and testable.
+
+---
+
+## How It Works
+
+A common mistake is defining projects using **activities, deliverables and outcomes interchangeably**.
+
+They're different.
+
+Consider:
+
+> **Migrate analytics to Umami.**
+
+### Activity
+
+Something someone does.
+
+Examples:
+
+- Install Umami
+    
+- Configure tracking
+    
+- Create dashboards
+    
+- Test events
+    
+- Write documentation
+    
+
+Activities consume effort.
+
+They aren't necessarily evidence of success.
+
+---
+
+### Deliverable
+
+Something the project produces.
+
+Examples:
+
+- Umami installation
+    
+- Tracking script
+    
+- Dashboard
+    
+- Documentation
+    
+- Tracking specification
+    
+
+Deliverables are tangible outputs of the work.
+
+But producing a deliverable doesn't automatically mean the desired outcome happened.
+
+---
+
+### Outcome
+
+The resulting capability or change.
+
+For example:
+
+> The organization can collect and analyze the required website analytics through Umami with validated data quality.
+
+That's much closer to the actual reason for doing the project.
+
+So:
+
+```text
+Activities
+    ↓
+Deliverables
+    ↓
+Outcome
+```
+
+For example:
+
+```text
+Configure tracking               Activity
+        ↓
+Tracking implementation          Deliverable
+        ↓
+Reliable analytics available     Outcome
+```
+
+A good project manager doesn't only ask:
+
+> "Did we complete the tasks?"
+
+They also ask:
+
+> "Did those tasks actually produce the result we wanted?"
+
+---
+
+## Definition of Done
+
+Once the outcome is clear, you need to define what "done" means.
+
+Suppose your project is:
+
+> **Remove Mogador**
+
+A weak Definition of Done would be:
+
+> Mogador migration completed.
+
+That simply restates the project.
+
+A better Definition of Done could be:
+
+- Required data flows no longer depend on Mogador
+    
+- Replacement synchronization has been validated
+    
+- Production has operated successfully on the replacement
+    
+- Monitoring is active
+    
+- Required documentation exists
+    
+- Operational ownership is established
+    
+- Mogador can be safely decommissioned
+    
+
+Now something important happens.
+
+Imagine the development work is finished but monitoring isn't implemented.
+
+Can you close the project?
+
+According to the Definition of Done:
+
+**No.**
+
+You have an objective basis for that decision.
+
+---
+
+## Example
+
+Consider your **Pipeline QA d'automatisation** project.
+
+A weak project description might be:
+
+> Automate QA.
+
+That's vague enough that the project could continue indefinitely.
+
+### Outcome
+
+A possible outcome:
+
+> Critical website functionality can be automatically validated before production releases, reducing manual QA effort and identifying regressions earlier.
+
+Now we understand **why** the project exists.
+
+### Possible Definition of Done
+
+The project might be complete when:
+
+- Critical test scenarios have been identified
+    
+- Automated tests exist for the agreed scenarios
+    
+- Tests run automatically as part of the deployment process
+    
+- Failed tests prevent or flag problematic deployments
+    
+- QA can review the results
+    
+- The process is documented
+    
+- Operational ownership is established
+    
+
+Notice that this doesn't necessarily mean:
+
+> Every possible website test has been automated.
+
+That could take forever.
+
+The Definition of Done creates a boundary.
+
+Version 1 can be completed.
+
+Improvements can continue afterward.
+
+---
+
+## How It Fits Into the Bigger Picture
+
+Lesson 1 gave us:
+
+> [[Projects vs Operations]]
+
+A project is temporary.
+
+But saying "projects have an end" creates another question:
+
+> **What exactly determines that we've reached the end?**
+
+That's where outcome and Definition of Done become important.
+
+Without them:
+
+```text
+Start
+  ↓
+Lots of tasks
+  ↓
+More requests
+  ↓
+More tasks
+  ↓
+"We're almost finished"
+  ↓
+More changes
+  ↓
+???
+```
+
+With them:
+
+```text
+Desired Outcome
+      ↓
+Definition of Done
+      ↓
+Required Work
+      ↓
+Execution
+      ↓
+Acceptance
+      ↓
+PROJECT CLOSED
+      ↓
+Operations / Product
+```
+
+This will connect directly to later concepts such as:
+
+- [[Scope]]
+    
+- [[Milestone]]
+    
+- [[Project Health]]
+    
+- [[Risk]]
+    
+- [[Stakeholder Management]]
+    
+
+Most importantly, **scope becomes much easier to manage once the outcome is clear**.
+
+When somebody asks:
+
+> "Could we also add X?"
+
+you can ask:
+
+> "Is X required to achieve the agreed outcome?"
+
+That doesn't automatically mean you reject it.
+
+It means you recognize that you're potentially changing the project.
+
+---
+
+## My Company / Real-World Context
+
+This concept is particularly relevant in your environment because projects frequently compete with operational work.
+
+Your team deals with:
+
+- Departmental projects
+    
+- Product initiatives
+    
+- Tickets
+    
+- Synchronization problems
+    
+- Production issues
+    
+- Data work
+    
+- QA
+    
+- SEO/WCAG
+    
+- Dependencies on DevOps
+    
+- Dependencies on Security
+    
+- External providers
+    
+
+Without a clearly defined outcome, interruptions make it very easy for a project to lose direction.
+
+You stop for an incident.
+
+You return two weeks later.
+
+Someone requests something new.
+
+Product has another idea.
+
+A dependency changes.
+
+Three months later the project is still active, but the original boundary has become unclear.
+
+A written outcome gives you an anchor:
+
+> **What were we actually trying to accomplish?**
+
+---
+
+### Example: Suppression de Mogador
+
+Instead of:
+
+> **Project:** Suppression de Mogador
+
+you might eventually have:
+
+**Outcome**
+
+> Systems currently dependent on Mogador use the approved replacement architecture, allowing Mogador to be safely retired.
+
+**Definition of Done**
+
+- Required Mogador dependencies identified
+    
+- Replacement implemented
+    
+- Required historical/current data preserved
+    
+- Synchronization validated
+    
+- Monitoring implemented
+    
+- Business/data validation completed
+    
+- Operational owner identified
+    
+- Mogador decommissioned
+    
+
+The exact criteria would depend on the real project, but notice how much more manageable the project becomes.
+
+You can now ask:
+
+> Which condition isn't true yet?
+
+Instead of:
+
+> How far along are we with Mogador?
+
+---
+
+## CTO Perspective
+
+At a technology-leadership level, one of the most important shifts is from managing **activity** to managing **outcomes**.
+
+A team can be extremely busy without producing the intended result.
+
+Consider an executive update like:
+
+> We had 14 meetings, completed 38 Jira tickets, configured the environments and finished development.
+
+Those numbers might be useful operationally.
+
+But an executive ultimately wants to know:
+
+> **Did we achieve what we committed to achieve?**
+
+A stronger update might be:
+
+> The replacement synchronization is now running in production and the data has been validated. Monitoring remains outstanding, so the project isn't ready to close yet.
+
+That's outcome-oriented communication.
+
+It also prevents the dangerous:
+
+> "Development is done, therefore the project is done."
+
+Development may only be one part of the outcome.
+
+---
+
+### Outputs vs Outcomes
+
+Technology organizations frequently report **outputs** because they're easy to count.
+
+Examples:
+
+> 42 tickets completed.  
+> 3 dashboards created.  
+> 12 APIs developed.  
+> 1,500 automated tests executed.
+
+Those aren't necessarily bad metrics.
+
+But a CTO needs to ask:
+
+> **What changed because we produced those things?**
+
+For example:
+
+**Output**
+
+> Automated synchronization monitoring implemented.
+
+**Outcome**
+
+> Synchronization failures are detected automatically before they create significant downstream data problems.
+
+The second tells you why the first matters.
+
+---
+
+### Questions to Ask
+
+- What problem are we actually trying to solve?
+    
+- What should be different when this project succeeds?
+    
+- How will we objectively know that the project is finished?
+    
+- Are we measuring completed activity or actual outcomes?
+    
+- Who accepts that the Definition of Done has been satisfied?
+    
+- Is this new request required for the outcome, or are we expanding the project?
+    
+- When the project finishes, who owns what we've created?
+    
+
+---
+
+## Meeting Scenario
+
+**Situation:**
+
+A project has been running for six months.
+
+Development says:
+
+> "We're basically done."
+
+Product says:
+
+> "There are still several things we wanted."
+
+QA says:
+
+> "We haven't fully validated it."
+
+Management asks:
+
+> "So... is the project finished or not?"
+
+Without previously agreed completion criteria, everyone can reasonably have a different answer.
+
+**Possible response:**
+
+> Before we call the project complete, I want us to validate it against the agreed outcome rather than simply whether development has finished. The implementation is complete, but QA validation and the production handoff are still required before we can close the project.
+
+Even better is preventing this situation by defining those criteria **when the project starts**.
+
+---
+
+## Key Takeaways
+
+- Projects should be defined by the **result they are intended to achieve**, not simply by a list of tasks.
+    
+- **Activities** are things we do.
+    
+- **Deliverables** are things we produce.
+    
+- **Outcomes** are the changes or capabilities those deliverables create.
+    
+- The **Definition of Done** establishes the conditions required to close the project.
+    
+- "Development complete" does not necessarily mean "project complete."
+    
+- A clear Definition of Done helps prevent projects from remaining open indefinitely.
+    
+- Clear outcomes make it easier to evaluate new requests and eventually control scope.
+    
+- Technology leaders should communicate **organizational outcomes**, not merely activity.
+    
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+    
+- [[Project Outcome]]
+    
+- [[Definition of Done]]
+    
+- [[Scope]]
+    
+- [[Scope Creep]]
+    
+- [[Milestone]]
+    
+- [[Project Health]]
+    
+- [[Stakeholder Management]]