Worked case

Estimate a Small Change When Approval Time Is Unknown

A practical example of separating hands-on effort from elapsed delivery time when approvals and integration can dominate the schedule.

The messy request #

A change looks small: update one configuration value, test it and move it to production. The hands-on work may take less than a day. The delivery date is still unclear because another team owns an approval and the next integration window is not guaranteed.

A weak estimate compresses all of that into one number. The result sounds precise but mixes effort, waiting and dependency risk.

Sources: Define the estimate object before estimating it · Estimate active effort and elapsed time separately

Step 1 — define what is being estimated #

First separate the objects. Hands-on effort answers how much active work the change needs. Elapsed time answers how long the request may take from start to usable production result. Those numbers can be very different and should not be forced into one value.

Write the estimate in two lines before discussing dates: expected active effort, then expected elapsed path with the external gates named.

Sources: Define the estimate object before estimating it · Estimate active effort and elapsed time separately

Step 2 — make approvals part of the delivery model #

The approval is not an invisible delay after the 'real work'. It is part of the delivery system. Name who owns it, what evidence they need, and whether the next step can start before approval arrives.

If the approval window is unknown, keep it as a range or an explicit dependency instead of padding the engineering estimate until the uncertainty disappears inside one large number.

Sources: Estimate approvals and integration as deliverables · Use a range when the uncertainty is asymmetric

Step 3 — narrow the range only when evidence changes #

Suppose active effort is 4–6 hours, while approval usually takes 1–3 working days and the integration window adds up to another day. A useful statement is not 'three days of effort'. It is '4–6 hours active work; likely 2–4 working days elapsed, mainly driven by approval and integration timing.'

If the approval is confirmed for this afternoon, the elapsed range can narrow. If nothing changed except pressure for a firmer date, the range should not become more precise.

Sources: Use a range when the uncertainty is asymmetric · Let ranges narrow only when uncertainty is actually removed

What the case produces #

The output is a small estimate record: scope, active effort, elapsed range, external gates, owner of each gate and the event that will trigger re-estimation. That is easier to update than a single date that silently absorbs every uncertainty.

This worked case is illustrative. Use the linked knowledge items to inspect the method, sources and limits before applying it to a consequential delivery commitment.

Put an idea to work

Define the estimate object before estimating itEstimate active effort and elapsed time separatelyEstimate approvals and integration as deliverablesUse a range when the uncertainty is asymmetricLet ranges narrow only when uncertainty is actually removed

Explore the topic

Project delivery