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/Estimation and Forecasting.md
+83 -80
View File
@@ -1,102 +1,105 @@
Duration: 30–40 minutes
Duration: 30--40 minutes
## Definition
Build realistic estimates and distinguish estimates, targets, and commitments.
This lesson is part of the Project Management track and builds on the concepts learned in the previous lessons.
Estimation predicts the effort or time required for work. Forecasting
combines estimates with capacity, dependencies, uncertainty, and current
progress to predict delivery. Keep **estimate**, **target**, and
**commitment** separate.
## 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.
**Estimate the work. Forecast the date. Agree on the commitment.**
## How It Works
We will examine this concept through four levels:
A target such as "leadership wants September 1" is not automatically an
estimate or commitment.
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.
Estimate milestone by milestone after outcome, scope, and major
dependencies are understood. Then account for real constraints.
## 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.
## 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.
## 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.
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.
## CTO Perspective
The leadership objective is to move progressively from personally coordinating work toward building a management system that produces reliable outcomes.
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
``` text
Requirements 1 week
Implementation 3 weeks
QA 1 week
Deployment 1 week
```
This does not automatically equal six calendar weeks. People have
operational work, dependencies create waiting time, work may overlap,
and uncertainty exists.
Use ranges when uncertainty is high. "6--9 weeks" can be more
responsible early on than false precision.
State assumptions:
> Six weeks assuming DevOps delivers the environment by Aug 10 and the
> owner has roughly 50% project capacity.
If assumptions change, the forecast should change.
### Example
An owner proposes eight weeks:
- 3 weeks implementation
- 1 week QA
- 1 week deployment
- 1 week Product validation
- 2 weeks availability/operational interruption
Do not simply change eight to five. Challenge the assumptions. Can work
overlap? Is the operational allowance supported by history? Can a
dependency start earlier?
### My Company / Real-World Context
Your projects are interrupted by tickets and production issues, so
project effort and calendar duration differ. An 80-hour project can take
many calendar weeks if only 10--15 hours per week are realistically
available.
### CTO Perspective
Aggressive dates do not create capacity. If a target must move earlier,
identify the trade-off: scope, priority, capacity, sequencing,
dependency acceleration, or increased risk.
### 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?
- What is the estimate based on?
- Which milestone has the most uncertainty?
- What assumptions are we making?
- What capacity is actually available?
- What is the requested target?
- What can the team reasonably commit to?
- What would need to change to deliver sooner?
## Meeting Scenario
### Key Takeaways
**Situation:**
- Estimate, target, and commitment are different.
- Forecasts combine effort with real constraints.
- Ranges are useful when uncertainty is real.
- Important assumptions should be explicit.
- Challenge estimates by challenging assumptions, not by arbitrarily
shortening them.
- Faster delivery normally requires a trade-off.
A project owner gives you an update, but the information does not make it clear whether the project will achieve its intended outcome.
## How It Fits Into the Bigger Picture
**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.
## 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.
This lesson builds on [[Projects vs Operations]], [[Outcomes and
Definition of Done]], [[Scope and Scope Creep]], and
[[Milestones vs Tasks]]. It prepares the project system to become
more predictable and scalable.
## Related Concepts
- [[Projects vs Operations]]
- [[Project Outcome]]
- [[Definition of Done]]
- [[Scope]]
- [[Milestone]]
- [[Dependencies]]
- [[Capacity]]
- [[Risk]]
- [[Project Health]]
- [[Portfolio Management]]
- [[Milestones vs Tasks]]
- [[Dependencies]]
- [[Prioritization]]
- [[Capacity and WIP]]
- [[Risk Management]]
- [[Project Health]]
- [[Portfolio Management]]