When I took over a software department several years ago and was suddenly confronted with the responsibility for a multi-million dollar budget for a really challenging project I was quite overwhelmed with the difficulty of the decisions I had to make. After lots of sleepless nights and feelings of sickness, I did what everybody would do: read 14 books about decision making. And it helped. After absorbing all that knowledge and applying and refining my decision skills over the years, I have found out, that there is a quite easy algorithm in making difficult decisions. It is an 8 step process.
1. Understand the problem
Very often, when I was confronted with a decision, I had no clue at all what I should do. I didn’t even understand what the decision was all about. So I had to dig into it and ask dumb questions like a 3 year old until I finally got my head around it. Most situations are more complex than they seem or people like to admit. I see it very often that a decision maker does not take the time to really understand the problem in depth. This is a mistake. Usually I dive into multiple levels of analysis before I feel that I’ve understood the problem.
2. Specify the goals
A decision is made to reach one or several goals. If there is no goal, then there is no decision. So I clarify what I would like to achieve with the decision. Only after that I can evaluate different alternatives. The system of goals should be straight forward and not too complicated. And it should pass the “headline test”: If you can replace the headline of the decision with something else, does the goal system still make sense? If yes, then the goal system is to general and should be made more specific.
3. Find the right level of analysis
Now I might start an iterative process: I start asking why I would like to reach these goals. Maybe there’s some greater more general goal that I would like to reach and maybe addressing this more general goal will open up more attractive alternatives. If the focus is to narrow, I might get stuck in a local optimum. After understanding the why, I might revisit step 2: I specify this more general goal system to replace the old goal system. But the newly specified goals must still pass the headline test. If they don’t, I’ve gone too far. It might need several iterations until I reach the most general but still useful goal system, but in my experience asking why just once, will do the job most of the time.
4. List the obvious alternatives
Usually there is a list of obvious alternatives. So I simply list them up. I always include the status quo as one of the alternatives, because doing nothing is always an option. This step is quite easy and does not need further exploration.
5. Find additional alternatives
This step should not be underestimated although it is often forgotten. I actively seek to generate new alternatives. A short brainstorming session will do. Also absurd alternatives are allowed. I suspend judgement and write everything within a certain range of usefulness down. If by now there are no alternatives that I immediately like, I use creative techniques. My favorites are: combinatorics, the reversal method, progressive abstraction, fractionation and analogies.
6. Reduce the alternatives
Now I can compare the alternatives regarding their potential to reach the specified goals. There might be probability estimation involved. I usually do the assessment in my head and I do not recommend the typical weighted matrix approaches. For me such a matrix looks like false rationality. But there are usually some alternatives that are obviously bad in their potential to reach the goals so I can rule them out. Sometimes I also do a so called dominance test: I look for alternatives that are worse or equal to another alternative in every aspect. Such alternatives can be crossed off the list.
7. Optimize the alternatives
Then I might end up with a list of alternatives and every one of them is ok but not great. Now I try to optimize them. Seeing listed alternatives as immutable is a big mistake. Maybe two alternatives can be combined to create a new one or some minor change in one mediocre alternative turns it into a great alternative. Maybe a risk contained in one alternative can be mitigated by some good risk management techniques. Maybe I create a “prototype-alternative”: I would pick one alternative but I only test if it would work with as little effort as possible and evaluate it after some time.
8. Decide
When I have an optimized set, usually one of the alternatives is obviously the best and I simply pick it. When I’m still unsure, I might revisit step 7. But if still more alternatives are seemingly equal, I try to use the “one sentence rule”: I try to reduce the decision to one single sentence (usually a question). Whichever alternative is the best according to this sentence, I will pick.
9. Conclusion
I have used this process over and over again in a variety of decision situations. I even use it during coding when I cannot decide upon a class design for my new feature in my object oriented framework. What I’ve omitted in this article is the so called “meta-decision”. The decision about how I will design the decision process. Actually the “meta-decision” is not a single decision but a constant evaluation of the effectiveness and efficiency of the decision process during its application. It starts before applying the process that is described here and it accompanies the decision process itself. However, the meta-decision is out of the scope of this article, but I might revisit this topic in a separate article.
The Nerd Manager 