From c3b430d0f6cea278c8076543a96caf2d03ef0029 Mon Sep 17 00:00:00 2001
From: modji <info@modji.ca>
Date: Thu, 23 Jul 2026 13:35:00 +0200
Subject: [PATCH] vault backup: 2026-07-23 13:35:00

---
 .../Scope and Scope Creep.md                  | 620 ++++++++++++++++++
 1 file changed, 620 insertions(+)
 create mode 100644 10 Knowledge/CTO Academy/Project Management/Scope and Scope Creep.md

diff --git a/10 Knowledge/CTO Academy/Project Management/Scope and Scope Creep.md b/10 Knowledge/CTO Academy/Project Management/Scope and Scope Creep.md
new file mode 100644
index 0000000..5e2fa34
--- /dev/null
+++ b/10 Knowledge/CTO Academy/Project Management/Scope and Scope Creep.md	
@@ -0,0 +1,620 @@
+Duration: 30–35 minutes
+
+## Definition
+
+**Scope** defines the boundaries of a project.
+
+It answers:
+
+> **What is this project responsible for delivering, and what is it not responsible for delivering?**
+
+A project's scope normally includes:
+
+- What will be delivered
+    
+- Which systems, features, teams, or processes are affected
+    
+- What work is included
+    
+- What is explicitly excluded
+    
+- Important constraints or assumptions
+    
+
+**Scope creep** occurs when additional work is added to a project without properly reconsidering the impact on time, resources, priorities, or the agreed outcome.
+
+The important distinction is:
+
+> **Change is not the problem. Unmanaged change is the problem.**
+
+---
+
+## Simple Mental Model
+
+Think of scope as a box:
+
+```text
+              PROJECT
+┌────────────────────────────────┐
+│                                │
+│     Work required to           │
+│     achieve the outcome        │
+│                                │
+└────────────────────────────────┘
+
+"Could we also add X?"
+          │
+          ▼
+   Is X inside the box?
+```
+
+If not, you have three legitimate choices:
+
+> **Reject it, replace something else, or expand the project.**
+
+What you shouldn't do is silently add it while keeping the same expectations for deadline and capacity.
+
+---
+
+## How It Works
+
+Lesson 2 established:
+
+> **Outcome = where we're trying to go.**  
+> **Definition of Done = evidence that we've arrived.**
+
+Scope defines:
+
+> **What journey have we agreed to take to get there?**
+
+Consider a project:
+
+**Implement Umami analytics**
+
+### Outcome
+
+> The organization can independently collect and analyze the required website analytics using Umami with validated data quality.
+
+### In Scope
+
+For example:
+
+- Deploy Umami
+    
+- Configure production environment
+    
+- Implement tracking on agreed websites
+    
+- Define required events
+    
+- Validate tracking
+    
+- Create required dashboards
+    
+- Document the implementation
+    
+- Establish operational ownership
+    
+
+### Out of Scope
+
+Potentially:
+
+- Replacing the organization's entire data warehouse
+    
+- Rebuilding unrelated Power BI reports
+    
+- Redesigning website consent management
+    
+- Building a full CDP
+    
+- Replacing every GA4 use case
+    
+- Tracking mobile applications
+    
+
+Those things might all be valuable.
+
+But:
+
+> **Valuable does not automatically mean part of this project.**
+
+---
+
+### Scope should follow the outcome
+
+A useful test for proposed work is:
+
+> **Is this necessary to achieve the agreed outcome?**
+
+Suppose someone says:
+
+> "Since we're implementing Umami, could we also create personalized audience segments?"
+
+Ask whether that is necessary for the agreed outcome.
+
+If the outcome is simply reliable independent web analytics:
+
+Probably not.
+
+That doesn't mean:
+
+> "No, we're never doing it."
+
+It means:
+
+> "That's a separate requirement. We need to decide whether we're adding it to this project or treating it as future work."
+
+That's scope management.
+
+---
+
+## Scope Creep
+
+Imagine the original project contains:
+
+```text
+Umami
+├── Installation
+├── Web tracking
+├── Event tracking
+├── Validation
+└── Dashboard
+```
+
+During implementation:
+
+Product:
+
+> "Can we add another website?"
+
+Marketing:
+
+> "Can we track campaign audiences too?"
+
+Management:
+
+> "Could this replace GA4 entirely?"
+
+Data:
+
+> "If we're doing this, maybe we should rebuild the reporting model."
+
+Developer:
+
+> "We could also automate the deployment."
+
+Individually, every request may sound reasonable.
+
+Three months later:
+
+```text
+Umami
+├── Installation
+├── Web tracking
+├── Event tracking
+├── Validation
+├── Dashboard
+├── Second website
+├── Campaign analytics
+├── GA4 replacement
+├── Reporting redesign
+├── Automated deployment
+└── Mobile tracking
+```
+
+But the deadline never changed.
+
+Then management asks:
+
+> "Why is Umami late?"
+
+This is classic scope creep.
+
+The project didn't necessarily execute slowly.
+
+**The project became larger while the original expectations remained unchanged.**
+
+---
+
+## Example
+
+Imagine a project initially approved as:
+
+> **Implement automated QA for critical website functionality.**
+
+### Original Scope
+
+**In Scope**
+
+- Identify critical user journeys
+    
+- Automate agreed tests
+    
+- Run tests before production deployment
+    
+- Generate failure reports
+    
+- Document the process
+    
+
+**Out of Scope**
+
+- Complete automation of every website test
+    
+- Performance testing
+    
+- Security penetration testing
+    
+- Mobile application testing
+    
+- Replacing all manual QA
+    
+
+Halfway through, Product asks:
+
+> "Could we automate visual regression too? It would help ensure everything stays beautiful."
+
+Potentially useful.
+
+But it's new work.
+
+The project owner should not simply say:
+
+> "Sure."
+
+They should identify it as a scope change.
+
+---
+
+## How It Fits Into the Bigger Picture
+
+Our first three lessons now form a chain.
+
+### Lesson 1: [[Projects vs Operations]]
+
+> Is this temporary work with an end?
+
+### Lesson 2: [[Outcomes and Definition of Done]]
+
+> What are we trying to achieve, and how do we know we're finished?
+
+### Lesson 3: [[Scope and Scope Creep]]
+
+> What work have we agreed belongs inside this project?
+
+Together:
+
+```text
+PROJECT
+   │
+   ├── Why does it exist?
+   │       ↓
+   │    OUTCOME
+   │
+   ├── What counts as finished?
+   │       ↓
+   │     DoD
+   │
+   └── What are its boundaries?
+           ↓
+         SCOPE
+```
+
+Only after those questions are reasonably clear does it make sense to create detailed tasks and schedules.
+
+Otherwise you can produce an excellent project plan for a poorly defined project.
+
+---
+
+## My Company / Real-World Context
+
+Scope management is especially important in your environment because your projects cross several organizational boundaries.
+
+A project can involve:
+
+- Your integrators
+    
+- QA
+    
+- Data
+    
+- SEO/WCAG
+    
+- Product
+    
+- DevOps
+    
+- Security
+    
+- Vendors
+    
+- Other business departments
+    
+
+Each participant can introduce legitimate requirements.
+
+That's where projects can quietly grow.
+
+---
+
+### Product relationship
+
+Product may identify something valuable during implementation.
+
+For example:
+
+> "While we're changing this page, could we also improve X?"
+
+The wrong PM lesson would be:
+
+> Always say no.
+
+The better response is:
+
+> **Understand the impact before committing.**
+
+Sometimes the answer should absolutely be yes.
+
+But then something may need to change:
+
+```text
+More Scope
+    ↓
+Potentially more
+├── Time
+├── Capacity
+├── Cost
+├── Risk
+└── Dependencies
+```
+
+This is sometimes called the **triple constraint** or project management triangle, commonly expressed through scope, time and cost/resources.
+
+The exact models vary, but the management principle is simple:
+
+> You generally cannot change one major project constraint indefinitely while pretending everything else remains fixed.
+
+---
+
+### Operational interruptions are NOT necessarily scope creep
+
+This distinction is particularly important for your team.
+
+Suppose an integrator is working on Umami.
+
+Then synchronization breaks.
+
+They stop Umami for two days and fix production.
+
+Did Umami's scope increase?
+
+**No.**
+
+The project was interrupted by operational work.
+
+That's a **capacity issue**, not scope creep.
+
+Compare:
+
+**Operational interruption**
+
+> "Stop working on Umami and fix the broken synchronization."
+
+Project scope didn't change.
+
+**Scope change**
+
+> "While implementing Umami, add tracking to three additional websites."
+
+The project itself became larger.
+
+This distinction will matter when diagnosing why your projects are late.
+
+---
+
+## CTO Perspective
+
+Technology leaders constantly receive good ideas.
+
+That's part of the problem.
+
+Many organizations don't suffer from a shortage of ideas. They suffer from an inability to decide **which ideas deserve resources now**.
+
+A CTO therefore needs to be comfortable saying:
+
+> "That's a good idea, but it isn't part of this project."
+
+Importantly, that isn't the same as:
+
+> "No."
+
+It could mean:
+
+> "Let's put that into the backlog."
+
+or:
+
+> "Let's make it Phase 2."
+
+or:
+
+> "If this is now more important than Feature X, let's replace X."
+
+or:
+
+> "We can include it, but we need to revise the timeline."
+
+This changes the conversation from confrontation to **trade-offs**.
+
+---
+
+### Your project owners should manage scope too
+
+This connects directly to our discussion after Lesson 2.
+
+Eventually:
+
+```text
+YOU
+ │
+ │ Approve project
+ ▼
+PROJECT OWNER
+ │
+ ├── Draft outcome
+ ├── Draft DoD
+ ├── Draft scope
+ ├── Build milestones
+ └── Propose timeline
+ │
+ ▼
+YOU REVIEW / CHALLENGE
+ │
+ ▼
+AGREED COMMITMENT
+```
+
+Once execution begins, the owner should also recognize:
+
+> "That's not in our agreed scope."
+
+They shouldn't necessarily reject the request themselves.
+
+They should **surface it**.
+
+For example:
+
+> "We can add that. It's outside the scope we originally agreed on, so I need to check the impact on the current milestone before committing."
+
+That's project ownership.
+
+---
+
+### Scope changes should be visible
+
+You don't necessarily need heavyweight change-control forms.
+
+For your environment, something lightweight could eventually be enough:
+
+```text
+## Scope Changes
+
+| Date | Change | Requested By | Impact | Decision |
+|---|---|---|---|---|
+| Aug 12 | Add second website | Product | +1 week estimate | Approved |
+```
+
+Now six months later, when someone asks why the original September deadline became October, you have organizational memory.
+
+That's much stronger than:
+
+> "There were a lot of changes."
+
+---
+
+### Questions to Ask
+
+- What exactly is included in this project?
+    
+- What is explicitly not included?
+    
+- Is this request necessary to achieve the agreed outcome?
+    
+- Is this a clarification of existing scope or genuinely new work?
+    
+- If we add this, what does it change?
+    
+- Should something else be removed?
+    
+- Should this become Phase 2 instead?
+    
+- Who has authority to approve a scope change?
+    
+- Has the timeline been updated to reflect the additional work?
+    
+- Are we blaming scope when the real problem is operational interruptions or insufficient capacity?
+    
+
+---
+
+## Meeting Scenario
+
+**Situation:**
+
+A project is already underway.
+
+Product asks:
+
+> "Since we're already working on this part of the website, can we add these three improvements? They're related and it would make sense to do everything together."
+
+The ideas are reasonable.
+
+Your developer says they can probably do them but warns that additional work is required.
+
+The original deadline hasn't changed.
+
+**Possible response:**
+
+> Those improvements make sense, but they're additional to what we originally committed to. Before adding them, let's estimate the impact. Then we can decide whether they belong in the current project, replace something already planned, or become a second phase.
+
+Notice what you didn't say:
+
+> "No."
+
+And you also didn't say:
+
+> "Sure."
+
+You forced a **decision**.
+
+That's the management skill.
+
+---
+
+## Key Takeaways
+
+- **Scope defines the boundaries of the project.**
+    
+- Scope should support the project's agreed outcome.
+    
+- **In scope** identifies what the project is responsible for delivering.
+    
+- **Out of scope** makes important exclusions explicit.
+    
+- Valuable ideas are not automatically part of the current project.
+    
+- **Scope creep is unmanaged expansion of project work.**
+    
+- Changing scope is legitimate when its impact is understood and accepted.
+    
+- Additional scope usually affects time, capacity, cost, risk, or other commitments.
+    
+- Operational interruptions are **not scope creep** if they don't change what the project must deliver.
+    
+- Project owners should identify and surface scope changes rather than silently accepting them.
+    
+- A technology leader manages new requests through **trade-offs**, not simply yes/no decisions.
+    
+
+## Related Concepts
+
+- [[Projects vs Operations]]
+    
+- [[Project Outcome]]
+    
+- [[Definition of Done]]
+    
+- [[Scope]]
+    
+- [[Scope Creep]]
+    
+- [[Milestone]]
+    
+- [[Capacity]]
+    
+- [[WIP]]
+    
+- [[Change Management]]
+    
+- [[Portfolio Management]]
\ No newline at end of file