perfect decisions, or timely decisions?

In my last post, I discussed Type A and B decisions, and looked at the concept of reversibility.

In this post, I want to exercise the idea of decision timeliness. The logic described is most suited to Type B, or reversible, decisions.

My question is whether it is better to wait to make the right decision, or to give an adequate decision now, and refine it later.

This is a common problem, and is one of the great contributors to “analysis paralysis”. In my field, we prize decision velocity over decision accuracy a large part of the time. It is not to say that a wild-arsed guess (technical term: WAG) is acceptable, because it simply isn’t. I suggest a considered decision that may be partially incorrect, today, is much more valuable than the totally correct answer some time in the future.

Note that I discuss this not as a black or white problem, but a shades of grey problem.

To illustrate the point, let us work through an example.

Imagine you are responsible for a software development project. Your project leader comes to you and says that she needs direction for a part of the project. You realise you can get back to her the next day, with an answer that is probably only 80% correct, or, if she waits 5 days, you will give her a complete, accurate, fully researched, justified, and 100% correct answer. Let us leave to one side the point of insufficient warning about this matter. As we have all experienced, things like this happen.

Conventional wisdom would suggest that, unfortunate as it may be, you should tell her that she is going to have to wait. We all know that getting the answer even partially wrong will certainly mean re-work, and re-work is an anathema. It costs money, it delays projects and can be detrimental to team dynamics and performance.

But, is this really correct?

Let us put some numbers and times to this example, and a surprising result emerges.

The first constraint we apply is that the team cannot be productively deployed elsewhere whilst they wait for a decision. In the real world, this constraint can be mitigated, but not always. It is imposed here to keep the variables to the decision timeliness and accuracy.

Let us say your team costs $10,000 per day, and the piece of work that your project manager needs direction on will take 20 days to complete. Your original budget is therefore $200,000 (20 days x $10,000/day) and your delivery date is 20 days out.

By asking her to wait, your project delivery goes to 25 days. This is the five-day wait, plus the 20 days to do the work. Your budget also blows out. You have 5 days of unproductive time whilst your $10,000/day team sit idle waiting for the decision, and then the original $200,000 project cost. You will be five days late, and have a budget over-run of 25%.

By taking the imperfect decision you avoid the unproductive time, but are forced into re-work. If we assume your first decision was, in fact, only 80% correct, then that means that 20% of what the team has done may need to be rejected when you deliver your perfect decision in five days’ time. At the end of this five days, the team has done 25% of the work, but 20% of that must be discarded, so they have only effectively done 20% of the work. Some simple arithmetic then says that the remaining 80% of the project will be done in 16 days, giving a total duration of 21 days, at a cost of $210,000.

This is one day late, with a budget over-run of 5%. And, most importantly, you have the same project deliverable as if you had waited for the perfect decision.

This is a simple model to build, and it provides some fascinating insights.

Significantly, the model is only partially sensitive to the original decision accuracy. In fact, there is no scenario in which this accuracy, or inaccuracy, puts you in a worse situation than had you delayed the initiative. Even if your decision was completely wrong, requiring 100% of the work to be discarded, you are in the same place as if you had waited. If your original direction is only partly correct, you are better off.

The most important thing the model tells us is that the timeliness of the decision is the critical factor. Put another way – there is no scenario in which waiting provides a better outcome.

In practice, you may not have the constraint of the unproductive team. Modern project management techniques might allow the initiative to be parked, and the next item commenced, allowing you to come back to this initiative later. However, this is not always possible – it may be a standalone initiative.

The reversibility of the decision is central – is it a Type A or B decision? If it is a non-reversible decision then a different approach will be necessary, and is something I will discuss in a later post.

The takeaway from this post is simple. Generally speaking, a good decision today is more valuable than a better decision in the future.