104 lines
3.0 KiB
Markdown
104 lines
3.0 KiB
Markdown
Duration: 30--40 minutes
|
|
|
|
## Definition
|
|
|
|
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
|
|
|
|
**Estimate the work. Forecast the date. Agree on the commitment.**
|
|
|
|
## How It Works
|
|
|
|
A target such as "leadership wants September 1" is not automatically an
|
|
estimate or commitment.
|
|
|
|
Estimate milestone by milestone after outcome, scope, and major
|
|
dependencies are understood. Then account for real constraints.
|
|
|
|
``` 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 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?
|
|
|
|
### Key Takeaways
|
|
|
|
- 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.
|
|
|
|
## How It Fits Into the Bigger Picture
|
|
|
|
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
|
|
|
|
- [[Milestones vs Tasks]]
|
|
- [[Dependencies]]
|
|
- [[Prioritization]]
|
|
- [[Capacity and WIP]]
|
|
- [[Risk Management]]
|
|
- [[Project Health]]
|
|
- [[Portfolio Management]]
|