Comparison
Cone of uncertaintyvsKnown unknowns
Cone of uncertainty
you were asked for a date before anyone had opened the vendor's documentation, and gave one.
The observation that estimates are wildest at the start of a project and narrow as work is done and unknowns are resolved. It is a reason to give ranges rather than points early, and to re-estimate as evidence arrives rather than defending the first number. The practical use in a conversation is to say where on the cone you are: an estimate made before a spike and one made after are different kinds of claim.
Full entry →Known unknowns
you could list what you did not know about the vendor's API, and that list was the plan.
The risks you know you have not resolved yet, as distinct from the ones you cannot see at all. The useful move in planning is to make the first list explicit and attack it early with spikes, because a known unknown is schedulable and an unknown unknown is only survivable through slack. A plan that contains no known unknowns has not been examined, it has been asserted.
Full entry →