vault backup: 2026-07-23 07:53:56

2026-07-23 07:53:56 -04:00
parent 72b42ebcaf
commit 1033a565cb
14 changed files with 1982 additions and 0 deletions
@@ -0,0 +1,673 @@
+Duration: 30–35 minutes
+
+## Definition
+
+A **task** is a specific piece of work that needs to be performed.
+
+A **milestone** is a significant checkpoint that demonstrates meaningful progress toward the project's outcome.
+
+The distinction matters because managers can easily drown in hundreds of tasks when what they actually need to understand is:
+
+> **Is the project progressing toward its outcome?**
+
+### Task
+
+Examples:
+
+- Configure DNS
+    
+- Create database
+    
+- Implement tracking script
+    
+- Write test cases
+    
+- Review documentation
+    
+- Configure deployment pipeline
+    
+
+Tasks represent **work**.
+
+### Milestone
+
+Examples:
+
+- Infrastructure ready
+    
+- Tracking implementation complete
+    
+- Data validation approved
+    
+- Production launch complete
+    
+- Operational handoff complete
+    
+
+Milestones represent **meaningful states reached by the project**.
+
+---
+
+## Simple Mental Model
+
+Think:
+
+> **Tasks tell the team what to do.**  
+> **Milestones tell the manager where the project is.**
+
+Or:
+
+```text
+TASKS → TASKS → TASKS → MILESTONE
+                         ↓
+TASKS → TASKS → TASKS → MILESTONE
+                         ↓
+TASKS → TASKS → TASKS → PROJECT DONE
+```
+
+You don't necessarily need to know whether task #37 is complete.
+
+You often need to know:
+
+> "Have we reached the production-ready milestone?"
+
+---
+
+## How It Works
+
+Consider a project to implement Umami.
+
+The project could contain dozens of tasks:
+
+```text
+- Create server
+- Configure database
+- Configure DNS
+- Configure SSL
+- Deploy Umami
+- Configure authentication
+- Add tracking script
+- Configure events
+- Test page views
+- Test custom events
+- Validate traffic
+- Compare data
+- Create dashboard
+- Write documentation
+- Train users
+...
+```
+
+All legitimate work.
+
+But imagine you're managing 12 projects.
+
+You cannot effectively manage:
+
+> 15 tasks × 12 projects = 180 individual tasks
+
+And that's a small example.
+
+Instead, you might manage Umami through five milestones:
+
+```text
+1. Infrastructure ready
+          ↓
+2. Tracking implemented
+          ↓
+3. Data validated
+          ↓
+4. Reporting available
+          ↓
+5. Production handoff complete
+```
+
+The project owner manages the tasks required to reach those milestones.
+
+You manage primarily through the milestones.
+
+---
+
+## What Makes a Good Milestone?
+
+A milestone should represent a **meaningful state**, not merely arbitrary progress.
+
+Weak:
+
+> 50% development complete
+
+Better:
+
+> Tracking implementation complete and ready for QA
+
+Weak:
+
+> Worked on infrastructure
+
+Better:
+
+> Production infrastructure ready
+
+Weak:
+
+> Meeting with Product completed
+
+Better:
+
+> Requirements approved by Product
+
+The second versions tell you something important about the project's state.
+
+---
+
+### Milestones should be verifiable
+
+Someone should be able to ask:
+
+> "Did we reach this milestone?"
+
+and get a reasonably objective answer.
+
+For example:
+
+> **Data validation complete**
+
+means agreed validation has occurred and the results were accepted.
+
+Compare that with:
+
+> **Data validation underway**
+
+That's a status, not a milestone.
+
+---
+
+## Example
+
+Let's use your **Pipeline QA d'automatisation** project.
+
+### Outcome
+
+> Critical website functionality can be automatically validated before production releases, reducing manual QA effort and identifying regressions earlier.
+
+### Possible Milestones
+
+**Milestone 1: Requirements approved**
+
+The team agrees on:
+
+- Which user journeys are critical
+    
+- What should be automated
+    
+- What remains manual
+    
+
+---
+
+**Milestone 2: Proof of concept validated**
+
+A small number of tests successfully run automatically.
+
+This reduces an important uncertainty:
+
+> Can our proposed approach actually work?
+
+---
+
+**Milestone 3: Critical test suite complete**
+
+The agreed critical scenarios have been automated.
+
+---
+
+**Milestone 4: Deployment integration complete**
+
+Tests run as part of the agreed deployment workflow.
+
+---
+
+**Milestone 5: QA acceptance complete**
+
+QA validates that the automation meets the agreed requirements.
+
+---
+
+**Milestone 6: Operational handoff complete**
+
+Documentation exists, ownership is established, and the system can move from project work into operations.
+
+Now compare that with:
+
+> Project is 70% complete.
+
+"70%" tells you surprisingly little.
+
+Knowing:
+
+> "The critical test suite is complete, but deployment integration hasn't started"
+
+tells you much more.
+
+---
+
+## How It Fits Into the Bigger Picture
+
+The first four lessons now build directly on each other.
+
+### [[Projects vs Operations]]
+
+> Is this temporary work?
+
+### [[Outcomes and Definition of Done]]
+
+> What are we trying to accomplish, and what counts as finished?
+
+### [[Scope and Scope Creep]]
+
+> What work belongs inside the project?
+
+### [[Milestones vs Tasks]]
+
+> What meaningful checkpoints show us that we're getting there?
+
+Together:
+
+```text
+                    OUTCOME
+                       │
+              Where are we going?
+                       │
+                       ▼
+                    SCOPE
+                       │
+             What are we delivering?
+                       │
+                       ▼
+                 MILESTONES
+                       │
+             How do we know we're
+                making progress?
+                       │
+                       ▼
+                    TASKS
+                       │
+               What needs doing?
+                       │
+                       ▼
+              DEFINITION OF DONE
+```
+
+This order is important.
+
+A common mistake is starting immediately with:
+
+> "Let's create all the Jira tasks."
+
+But you haven't necessarily established what the project is trying to accomplish yet.
+
+---
+
+## My Company / Real-World Context
+
+This concept is particularly relevant to how you should eventually divide responsibility between yourself and your project owners.
+
+You shouldn't need to manage every task performed by your integrators, analysts, QA, or SEO/WCAG person.
+
+The eventual system could look like:
+
+```text
+PROJECT OWNER
+│
+├── Tasks
+├── Detailed sequencing
+├── Day-to-day follow-up
+└── Contributors
+        │
+        ▼
+    MILESTONES
+        │
+        ▼
+       YOU
+```
+
+The project owner should be able to tell you:
+
+> "We're targeting milestone 3 for August 15."
+
+Your job becomes asking:
+
+> "Are we still going to hit August 15?"
+
+rather than:
+
+> "Did Jean complete Jira ticket ABC-234?"
+
+That is a significant difference between **managing projects** and **managing people's task lists**.
+
+---
+
+### Your Monday board
+
+This also gives us our first clue about what might eventually change in Monday.
+
+Your current portfolio has broad timelines.
+
+For example:
+
+```text
+Suppression de Mogador
+April 2026 ───────────────── January 2027
+```
+
+That tells you the project exists for approximately nine months.
+
+But imagine instead seeing:
+
+```text
+Suppression de Mogador
+
+Health: 🟡
+
+Current milestone:
+Replacement synchronization validated
+
+Target:
+September 15
+
+Next milestone:
+Production cutover
+
+Target:
+October 10
+```
+
+Suddenly you can understand the project without opening its entire task list.
+
+We aren't modifying Monday yet, but this is one concept that will eventually influence the design.
+
+---
+
+## Milestones and Dates
+
+Milestones usually have target dates.
+
+This is where something important happens with the problem you've already identified:
+
+> Your projects frequently get interrupted by operations.
+
+Suppose:
+
+```text
+Milestone:
+Tracking implementation complete
+
+Target:
+August 15
+```
+
+August 15 arrives.
+
+The milestone isn't complete because the owner spent eight days dealing with production incidents.
+
+Don't simply change:
+
+> August 15 → August 30
+
+and move on.
+
+The missed milestone contains **management information**.
+
+You want to understand:
+
+> Why did we miss it?
+
+Possible reasons:
+
+- Scope increased
+    
+- Estimate was wrong
+    
+- Operational interruptions
+    
+- Dependency wasn't available
+    
+- Owner didn't execute
+    
+- Requirements weren't clear
+    
+- Priority changed
+    
+- Technical problem appeared
+    
+
+Those causes require completely different management responses.
+
+A milestone isn't only a deadline.
+
+It creates a **checkpoint where reality meets the plan**.
+
+---
+
+## Milestone vs Deadline
+
+They're related but not identical.
+
+A **deadline** says:
+
+> Something must happen by this date.
+
+A **milestone** says:
+
+> The project has reached this meaningful state.
+
+A milestone commonly has a target date:
+
+> **Milestone:** Data validation complete  
+> **Target:** September 30
+
+This gives you both:
+
+**What should be true + when we expect it to be true.**
+
+---
+
+## CTO Perspective
+
+As you move higher in an organization, the level at which you manage should change.
+
+An integrator might think about:
+
+> What code needs to be written today?
+
+A project owner might think about:
+
+> What work needs to happen to reach the next milestone?
+
+You might think about:
+
+> Which projects aren't reaching their milestones?
+
+A CTO might think about:
+
+> Which strategic initiatives aren't delivering their expected outcomes?
+
+Think of it as levels:
+
+```text
+EXECUTIVE
+Outcomes
+    ↑
+YOU
+Projects / Milestones
+    ↑
+PROJECT OWNER
+Milestones / Tasks
+    ↑
+CONTRIBUTOR
+Tasks
+```
+
+This doesn't mean a CTO never looks at a task.
+
+It means they **shouldn't need to manage through tasks under normal circumstances**.
+
+---
+
+### Milestones also create accountability
+
+Suppose one of your project owners says:
+
+> "The project is going well."
+
+Your response can be:
+
+> "What's the next milestone?"
+
+They answer:
+
+> "Data validation."
+
+You ask:
+
+> "When?"
+
+> "August 20."
+
+Then August 20 gives you an objective point to review.
+
+Without milestones, project updates easily become:
+
+> "Still working on it."
+
+> "Making progress."
+
+> "Almost there."
+
+> "Waiting on a couple things."
+
+Those statements are difficult to manage.
+
+---
+
+### Don't create too many milestones
+
+Milestones are supposed to simplify project visibility.
+
+A three-month project probably doesn't need 25 milestones.
+
+If every task becomes a milestone, you've recreated the task list.
+
+A useful starting point might be around **3–7 meaningful milestones** for many of your projects, depending on size and complexity.
+
+The exact number isn't the important part.
+
+Ask:
+
+> **Would I care if this checkpoint wasn't reached?**
+
+If not, it probably doesn't need to be a portfolio-level milestone.
+
+---
+
+### Questions to Ask
+
+- What are the major states this project must pass through before completion?
+    
+- What's the next milestone?
+    
+- Who owns reaching it?
+    
+- What's its target date?
+    
+- What must be true before we consider the milestone achieved?
+    
+- Are we still confident in the target?
+    
+- What could prevent us from reaching it?
+    
+- If we missed it, why?
+    
+- Was the cause scope, capacity, dependency, execution, or something else?
+    
+- Am I managing the project through meaningful checkpoints or micromanaging individual tasks?
+    
+
+---
+
+## Meeting Scenario
+
+**Situation:**
+
+You ask a project owner:
+
+> "How's the project going?"
+
+They respond:
+
+> "Pretty good. We completed about 18 tickets. There's still quite a bit left, but we're making progress."
+
+This gives you very little useful information.
+
+**Possible response:**
+
+> What's the next milestone we're trying to reach, and are we still on track for its target date?
+
+They respond:
+
+> "The next milestone is production data validation on September 15. Development is nearly complete, but we're waiting on DevOps for the production environment, so September 15 is currently at risk."
+
+Now you have something actionable.
+
+The problem isn't:
+
+> "18 tickets completed."
+
+The management information is:
+
+> **Milestone at risk because of a cross-team dependency.**
+
+And because DevOps doesn't report to the project owner, that may be exactly the type of problem that should come to **you**.
+
+---
+
+## Key Takeaways
+
+- **Tasks represent work. Milestones represent meaningful progress.**
+    
+- Project owners should generally manage detailed tasks.
+    
+- Managers should primarily manage projects through outcomes, milestones, risks, and blockers.
+    
+- Good milestones describe verifiable states such as "QA accepted" rather than vague activity such as "working on QA."
+    
+- Milestones should usually have target dates.
+    
+- A missed milestone is useful management information and should trigger understanding of **why** it was missed.
+    
+- Don't automatically move milestone dates without understanding the cause.
+    
+- Too many milestones defeats their purpose.
+    
+- Milestones help you manage multiple projects without micromanaging every task.
+    
+- As leadership responsibility increases, management should increasingly move from **tasks → milestones → outcomes**.
+    
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+    
+- [[Outcomes and Definition of Done]]
+    
+- [[Scope and Scope Creep]]
+    
+- [[Milestones vs Tasks]]
+    
+- [[Dependencies]]
+    
+- [[Capacity and WIP]]
+    
+- [[Project Health]]
+    
+- [[Portfolio Management]]