Decisions and consequences

Early last year I wrote a post called, Thoughts on decision-making, where I outlined some decision-making techniques and myths. One item I would like to add to that topic is to understand the consequences and ramifications of the decisions you make.
Let's step back and examine this from a business context. Suppose we are working on a project and one of the requirements is simply, "to be able to process transactions from external sources." The design team proposes two solutions:

• Processing batch files
• Processing individual transactions (real-time)
  

Based on cost estimates, the batch file solution seems more appealing. One should consider whether, in the foreseeable future, real-time processing is desirable and whether the benefits of that approach will outweigh the increase in costs. It may turn out that the batch file design still wins out but the ramifications of the decision are fully understood and can be communicated.

You may think the consequences of a decision will be minor and short-lived, but they may become temporary like income taxes.

Knowing when it's good enough

A business uses cost-benefit analysis as one of its evaluation criteria when deciding whether to pursue an opportunity or not. One concept central to this is the assessment of potential risks. To me there are a few components to risk assessment:

1. Likelihood of the risk materializing. What's the probability of the risk becoming a problem?
2. Potential cost (monetary, compliance or reputation) to mitigate the risk. How much is it going to cost you? This also includes implementing any mitigation strategies.
   

Combined, these factors provide a value to each risk. Risk assessment can be applied in many different areas:

• Managing the risks encountered in a project.
• Understanding the importance of a defect or bug in a system.
• Managing financial assets.
  

For the purposes of this post I'm only going to write about the second item.

What do you do if you find a defect or bug in a system? You evaluate it to determine whether it's a show stopper or whether you can proceed despite it. Creating bug-free software is the ultimate goal but it has cost and time implications. Here's a quote from an article, They Write The Right Stuff, from Fast Company about a specific software system.

This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.

The piece of software in question runs the NASA space shuttle. The consequences of failure could result in the deaths of the astronauts, the loss of a multi-billion dollar piece of hardware and many years of setbacks to the space program. Many of the systems we deal with in the business world do not have this level of criticality. In my past jobs I have worked with time sensitive trading systems where 1/2 second delays mean losses in the $10,000's of dollars. On other projects, variances in marketing and market research data were explainable ("Yes, someone did purchase 50 rolls of toilet paper and it skewed the numbers.") We need to understand when something is good enough as it is instead of always trying to be perfect.

Thoughts on decision-making

According to new research on the Discovery Channel's website, cockroaches get together to make group decisions about things that affect them as a community. Even more astonishing, cockroaches do so without being able to make sounds. Perhaps, we can learn something about the science of decision-making from them.

Common myths about decision-making

1. The more time I spend analyzing before making a decision, the better the decision I will make. Sometimes you can spend too much time making a decision. Your indecision could allow a competitor to seize the initiative.
2. In retrospect, a decision that did not work out was a bad one. Because something did not work out does not mean a bad decision was made. There are many things that are beyond your control that can affect a situation and cause an undesirable outcome. This does not imply the decision was incorrect.

What's it worth?
Here are some basic questions that you should consider to understand the importance of a potential decision.

• Does it contribute towards meeting your goals or objectives?
• Does it contribute towards the goals and objectives of the company or greater good?
• What is the risk associated with an inappropriate choice?
• How much time are the key decision-makers and you willing to provide? If no one is willing to give time, then how important do they really view it? (I'm a little draconian here, I'll admit.)
• What are the associated benefits and costs of making the decision?
• What happens if I do nothing?

Some decision-making techniques

To help you with your decision-making needs I have listed off a few different techniques that may be useful.

• Paired comparison analysis is very useful when there are defined alternatives. The basic premise is to use a grid to directly compare one alternative versus another. The alternative that wins out against the others the most will be chosen.
• Use a SWOT analysis to evaluate different solutions to a problem or opportunity. This will give you an understanding of their overall appropriateness.
• Grid analysis involves comparing alternatives against a defined set of important criteria. The winning alternative will be the one that scores the best.
• When you have a few different issues to address and you are trying to determine which one to attack first, Pareto Analysis, can be very useful. It involves identifying the most pressing problems.
• Decision-trees are very useful to help you visualize all of the possible outcomes. You need to be able to estimate the likelihood of a path being followed as well as the value of the path (e.g., outcome.)
• One can use the 6 Thinking Hats methodology to examine the different aspects of a situation before settling on a solution. This methodology was developed by Edward de Bono and can be applied to innovative thinking as well as decision-making.
• Force field analysis is extremely useful to understanding the different forces that affect an issue. The great benefit from this technique is that it will illustrate all of the areas that will be impacted and may require a change management process because of a pending decision.

Some other great resources

• Mindtools
• 6 Thinking Hats
• Management Methods

Stay committed to your decisions, but stay flexible in your approach. (Tom Robbins)

A problem solving paradigm

Understand the problem
You need to be able to understand the situation and identify the root cause(s) and not just handle the symptoms.

Ask the why questions without making them sound like they are why questions. You're trying to understand the problem not lay blame. Be careful to avoid using language that is not objective or could be interpreted as finger-pointing. Telling someone, "Your transaction processing system screwed up," will only lead to a very defensive response and an escalation in tension. Instead say something like, "I think there may be an issue with the processing of a transaction. Let's investigate one through the whole process to see where the problem occurs."

Even if someone blames you for the issue, maintain your objectivity and abstain from escalating the situation.

Figure out what options you have
Identify the steps you will need to move from your current position to your desired one. Come up with different options that are available. Listen to people who have different ideas; support innovation. Be innovative and introduce different ways of reaching a solution.

Choose the best alternative
Weigh the options against each other using a SWOT analysis. Lock in on the best option and go for it.

Learn from experience
After the problem has been solved and victory declared, spend time to learn from the experience.

• If new processes or procedures worked during an emergency. Perhaps they should be implemented during other circumstances.
• Take precautions to ensure the same problem will not happen again.