The finesse with which a project team or company makes decisions is an indicator of the potential success of the project and company.

The easiest way to make decisions is with a guru. This is the person who understands the customers, applications, technologies, team and the project/business constraints. The guru makes the decisions in a way that they “stick” either through consensus building, power, or influence. Does this sound like the definition of an entrepreneur? In many cases it is the formula that makes for a successful one.

Sometimes the decision is too complex, or a guru is not available, or the team doesn’t buy into the decision. Those are times when you may want to use more formal decision tools.

While the two decision processes I will describe are helpful, they are most importantly a forum for the team to talk about the criteria that make up the decision, the importance of the criteria, and how the criteria are satisfied by the team’s choice of outcomes.

For Most Decisions - Decision Matrix

The most straightforward method is a decision matrix that I attribute (perhaps incorrectly) to Kepner-Tregoe (www.kepner-tregoe.com). My interpretation is a simple matrix where the criteria are listed in rows, the alternatives in columns with the first column containing the relative importance of the criteria. I usually use a scale of one (poor) to five (strong) to score how well each decision criteria is served by each decision alternative. Then with some simple arithmetic a score for each decision alternative is calculated where the high point score wins.

The problem with this method is that it is too easy to “fudge” it by consciously or subconsciously manipulating the scores to achieve a desired outcome. A review of results from this method must include a reasonableness check. The advantage of this method is that it is straightforward and intuitive.

For Complex Decisions - Analytical Hierarchy Process

For complex decisions, my preferred method is the Analytical Hierarchy Process. I have used this for over 20 years and in my opinion, when this process is used, the quality of the decision is assured.

This process is well suited to complex decisions and has a unique feature in that it measures the quality of the input used to make the decision. It does this by calculating a consistency factor for the completed work. If the work does not measure up, the consistency factor will show that the team should rework the analysis. In my experience, when the teams understands and agrees on the problem, understands the decision criteria, and there are no hidden agendas, consistency is rarely a problem. On the other hand, if there are hidden agendas or incomplete understanding of the problem, it can take a long time to get all of the facts straight.

There is a learning curve for this process. You should expect to spend 40 to 80 hours to learn it well enough to tackle a first project, and plan on using it several times before you tackle something complex while facilitating a group of people working on a decision.