One of the core concepts of #NoEstimates. Probability is input to decision making. Even a small probability of being late must drive the decision to cut scope.
In the absence of a software development context, this statement has some merit. But the cutting of scope is not the only option.
- Before that delivery date - which will be late - it must be decided and communicated the customer or negotiated with the customer, an assessment of the aleatory and epistemic risks to that date must be done. This assessment will provide a model of the needed margin - schedule margin, cost margin, and technical performance margin, that will be used to protect that date, cost, and technical performance.
- When the Epistemic (reducible) risks are identified that will impact that delivery date, explicit activities in the project must be taken to correct or prevent those risks from the unfavorable impact on that decision.
- Alternative Points of Integration are used in our domain all the time to provide alternative paths to the needed scope. As the project progresses, these alternative paths to Done are assessed to determine if they should be taken, verses of the originally planned paths.
- The paradigm of Analysis of Alternatives (AoA) is a mandatory process in our domain. This AoA is performed periodically or when the risk to meeting the delivery date, at the needed cost, with the needed capabilities, triggers an assessment.
These activities come from Tim Lister's quote
Risk Management is how Adults Manage Projects. Be an adult, establish, follow, and benefit from a risk management process
Along with the first fallacy is another common fallacy in the #NoEstimates paradigm
Well, don't give promise to a client with a deadline when you are uncertain. Establish certainty first.
In the software development business, or for that matter, any business there is no such thing as certainty. As Steve reminds us,
In order to make that original plan for a product or a service, we must identify the aleatory (reducible) and epistemic (irreducible) uncertainties that will impact the performance of the project (cost, schedule, and technical performance).
Establishing certainty first - is a fool's errand. There is no such thing as a certainty - only a probabilistic assessment, with a confidence level of some probabilistic outcome.
Whatever you are trying to do requires risk management. The risk from reducible and irreducible uncertainty. The reducible risk can be reduced with explicit work activities in an increase of knowledge of the uncertainty. This is paid for by the project. It's called risk buy down. The risk produced by irreducible uncertainty is addressed by a margin. Schedule margin, cost margin, technical margin.
The Fallacies
- It is a fallacy that scope must be cut. Cutting scope is one of many actions that can be taken.
- Establishing certainty is physically impossible in any project or product development effort.
Both these fallacies ignore the established process of Managing in the Presence of Uncertainty
