Bad Decisions Are Costly, Early Bad Decisions Are More Costly

Have you ever made a bad decision? The correct answer is “No, I’ve made many bad decisions.” [Sorry, no other response is acceptable.]

Project teams make many bad decisions. Bigger teams and longer projects result in many more bad decisions along the way. Why does this happen?

• The information being reviewed is wrong and no one realizes it.
• The data being analyzed is incomplete and misleading.
• The people making the decision don’t have sufficient experience to draw upon.
• The team feels pressured to do something they don’t feel good about.
• Someone lied (vendor, customer, manager, Scrum Master, Product Owner, etc).

(That last one is egregious and rare but it happens.) Thankfully, most bad decisions are minor and easily corrected. In most cases, making a bad decision is better than making no decision and leaving the team paralyzed.

Here lies a major weakness of BDUF (Big Design Up Front). Intelligent people don’t like to admit that some of the many detailed decisions they have to make on a project will prove to be bad, or at least much less than optimal. By the time those bad decisions have surfaced, code will have been written, test routines implemented, etc. The cost of fixing those issues is likely to be much higher than the cost of preventing them.

What can you do?

Clearly, any steps you can take to help the team make better decisions can only help. A simple approach is to help the team to self-organize so that major decisions can be made collectively. This is not easily done but start by reviewing the 12 Principles behind the Agile Manifesto. Encourage the whole team to be open, visible and collaborative.

Making this work well also requires just-in-time decision-making. It may be uncomfortable at first, but you really need to make decisions as late as possible in the project. Later usually comes with better information and greater knowledge. That doesn’t mean you should avoid decisions. It means not making them if you don’t need to.

There are always exceptions.

Life isn’t perfect and the above principles won’t always work. Sometimes a client or prospect (e.g. an RFP response) demands a detailed description of what the team will do, when they will do it, and how much it will cost. If you want to play, you have to make many design decisions up front. You can give yourself some wiggle room, but if you deviate too far from what you proposed, you could be in violation of an implied or written contract.

There are many ways to handle these situations and they mostly boil down to gaining the client’s trust so you are given greater flexibility. Agile approaches can be used in rigid, even fixed-price environments, if the client is willing to grant flexibility in at least one area — scope or time. If not, a command-and-control approach (i.e. one of the many waterfall variations) with a structured change control system will be needed.

Progress is making new mistakes.

The key word in the last sentence is ‘new’. Repetitive mistakes are killers and that’s why we use retrospectives to identify and eradicate them. New mistakes are okay — just make them as late in the project as possible.