Good plans lead to good decisions.
A good decision is one we'd make again the same way with the information.
That doesn't necessarily mean what you think it does.
Suppose I offer you the chance to win $100 on a single roll of a normal six-sided die.
You have two options.
you can bet on rolling a one or you bet rolling everything other than a 1. If you choose correctly, you win the $100. Assuming a fair game,
there's an equal chance of rolling any number.
So there is a one in six chance that you'll roll a 1. There's a five in 6 chance you will roll something other than one.
It should be clear that your best option is to bet on rolling a 2, 3, 4, 5, or 6. And so that's what you bet.
What happens then when you roll the die and throw 1? You don't win a gamble, but was betting on 2 through 6 the wrong decision?
To answer that, how would you bet if I gave you the chance to roll the die again?
You would again bet on rolling a 2 through 6. Rolling a 1 in this decision is bad luck, but it doesn't mean betting on 2-6 was a bad decision.
Let's put this in the context of a development project.
You follow all the best practices in Agile planning and conclude that a project can be delivered in four to six months.
Based on that plan, management greenlights the project in deciding to approve the product.
Management should consider the four-to-six-month plan and compare it to the projected benefits of the projects, such as increased revenue,
customer satisfaction, or cost savings.
Management might reason that the project will be a bargain if finished in four months, a good deal if delivered in five,
and they project an acceptable but not exciting return even if it takes the full six months.
The project progresses nicely at first, then some unanticipated bad luck strikes and the product is completed in seven months – a bit longer than the anticipated
four to six.
Does this mean the plan led management to make a bad decision?
Not necessarily.
As with rolling the die, imagine you could run the same project 100 times with no learning between successive runs of the project.
Would it almost always take four to six months just as the dye would almost show two through six?
There might be occasional bouts of bad luck and the projects take seven or even more months.
And there could be occasions of good fortune with the project being completed in only three months.
But these are outliers.
They're like rolling one on the die four times in a row.
Management has every right to be disappointed if they're told four to six months and a team takes seven months to deliver.
but management does not have the right be angry about it if it was just like the random bad luck of rolling a one.
I encourage teams to communicate plans they feel they can meet 90% of the time.
Theoretically, that means there's a 5% chance of finishing earlier and a five percent chance at being later.
More practically, even teams that are good at estimating may provide plans that accurate 80% and that will be too low 20% There's a difference between
being wrong and making a bad decision.
If I bet that a die will come up with a two through six and it doesn't, I was wrong, but I did not make a decision bad.
This is an important distinction for both teams and management to understand.