Estimation and Missed Commitments | Free Lesson

This lesson gives you a method for building the estimate and a Commitment Risk Template for the moment the plan starts to move.

Lesson details: 40 minutes · on-demand written lesson and practical artifact · developed and reviewed by IT Modality Academy.

Do not smuggle uncertainty into a single date.

An estimate should expose:

• the work being estimated;

• the definition of complete;

• assumptions and unknowns;

• dependencies and capacity;

• the method or comparison used;

• a range or confidence statement where uncertainty matters; and

• the next point at which new evidence will revise it.

A commitment adds a decision: someone accepts the scope, tradeoffs, date or checkpoint, and response when conditions change.

“Two weeks” without those inputs is not precision. It is an unlabeled guess.

1. Bound the outcome

What exact work product or accepted state ends the estimate? Separate included work from desired but unapproved work.

2. List assumptions and unknowns

An assumption is something the estimate currently treats as true. An unknown is evidence you still need. Both belong beside the number or range.

3. Name dependencies and ownership

Access, data, review, third-party response, environment, and decision delays can move delivery even when execution is sound. Name who owns each dependency.

4. Choose the estimation basis

Use decomposition, prior comparable work, a spike, throughput evidence, expert review, or another stated method. Do not claim a method is reliable beyond the evidence available.

5. Define the review point

State when you will update the estimate: after discovery, sample validation, design approval, environment access, or another evidence checkpoint.

Raise risk when a decision can still change the outcome.

Do not wait until the committed date is impossible. Define a warning threshold in advance:

• a dependency misses its needed checkpoint;

• actual work reveals a new scope class;

• defect/rework exceeds the assumption;

• access or environment remains unavailable;

• the acceptance rule changes; or

• the remaining capacity no longer supports the commitment.

A warning states the evidence, consequence, options, recommendation, and decision owner.

Bring choices, not a hidden miss.

Common choices are:

• keep the outcome and move the checkpoint;

• keep the checkpoint and reduce approved scope;

• add a capable resource when onboarding cost and access make that useful;

• change sequence to protect a critical dependency;

• accept a documented risk; or

• stop and re-scope when the original premise no longer holds.

Do not present overtime, silent quality reduction, or unapproved scope removal as a recovery plan.

Commitment: Complete test evidence for the approved interface scope by the release checkpoint.

New evidence: Two source fields changed after mapping approval, and the receiving team has not approved expected values.

Consequence: The full scope cannot reach valid acceptance evidence at the current checkpoint.

Options:

1. Move the checkpoint after field approval and complete full regression.

2. Keep the checkpoint, remove the two changed fields through a documented scope decision, and test the approved remainder.

Recommendation: Use option 2 only if the business owner accepts the reduced pilot scope; otherwise move the checkpoint.

Decision owner: Named business/data owner.

Commitment Risk Template

Outcome/commitment:
Current checkpoint/date:
Definition of complete:
Original assumptions:
New evidence:
Dependency and owner:
Warning threshold crossed:
Consequence if unchanged:
Option 1 — scope/time/quality effect:
Option 2 — scope/time/quality effect:
Recommendation and why:
Decision owner and needed-by point:
Next evidence checkpoint:
Record/link location:

Estimate quality check

• Is the outcome bounded?

• Are assumptions visible beside the estimate?

• Is uncertainty described without false precision?

• Are dependencies assigned?

• Is there a review point before the commitment fails?

• Does recovery preserve quality or explicitly seek a tradeoff decision?

Fallback: “Developed by IT Modality Academy.” No named/credential material renders before approval.

Next: definition of done, QA, and documentation

Continue to definition of done Previous Index Related bootcamp

Firewall: Lesson/signup does not affect The Rigors or work. See /legal/training-work-firewall.