Decide How to Decide

Of all the legacies of the 1986 Challenger space shuttle explosion, perhaps none is more chilling than the words of the Rogers Commission's report, the official analysis of what went wrong. "There was a serious flaw," says the report, "in the decision making process leading up to the launch." Among other problems it identifies, the report makes this telling observation: "NASA appeared to be requiring a contractor to prove that it was not safe to launch, rather than proving it was safe" (see "The Presidential Commission on the Space Shuttle Challenger Accident Report, June 6, 1986 p.82, p.104, p.117-118 available at: www.ksc.nasa.gov/shuttle/missions/51-l/docs/rogers-commission/table-of-contents.html. A detailed assessment of the decision making is described in Randy Hirokawa, Dennis Gouran and Amy Martz's "Understanding the Sources of Faulty Group Decision Making: A Lesson from the Challenger Disaster," Small Group Behavior, Vol. 19, No. 4, Nov. 1988).

One flaw that contributed to the tragedy was that no one had clearly defined what would constitute the components of the decision to launch the shuttle; no one had decided how to make the key go or no-go decision.

Chances are, the decisions made by your software development team do not have this kind of immediate, life-or-death impact. But the many decisions involved in a software project affect the professional lives of numerous stakeholders: users, designers, builders, testers, managers, marketers, customers and others. For some decisions, the financial stakes are high, while others may require organizational change.

These decisions range from determining which requirements to include in a given release to defining what "quality" means for a given product. They also involve project structural issues, such as which work products to create and how to distribute work on a team. While making other typical decisions you may ask, how do we involve users? When do we declare the design process finished? How will we know the test plan is complete? How will we know when the product is ready for release?

These kinds of decisions, and many others, require a decision leader—someone to "make the call." But the decision-making difficulties that plagued the Challenger and often software projects, reveal leadership alone is not the solution. The culprit is not a flawed leader but rather a flawed decision-making process. If you care about a particular decision, it matters how the decision is made as well as who makes it.

For decisions that will create important consequences and require support by all the team members, the best course is to follow a pattern of collaborative decision making.

Collaborative Decision Rules
A collaborative decision is one in which stakeholders participate in the decision-making process in a way that meets the needs of individuals and the group, includes the diverse views of all stakeholders, and enhances the group's ability to continue to work effectively together. In decisions that aren't collaborative, stakeholders aren't consulted or their input is obtained without inquiring into the reasoning behind their thinking.

According to Paul C. Nutt, in "Leverage, Resistance and Success of Implementation Approaches," the most successful decisions are those in which a decision leader gathers sufficient information and then enables the stakeholders to make the decision (Journal of Management Studies, Vol. 35, No. 2, Mar. 1998). This is another way to define a collaborative process (see Table 1). A collaborative decision requires skills in problem solving, facilitated discussions, group evaluation and decision making.

The first step in collaborative decision making is to determine the rule by which you will make the decision, known as the decision rule. Identifying the decision rule is the responsibility of the decision leader. This person has the authority to implement the decision or obtain resources to implement it, and she ensures that the decision is supported in the organization. In the organization chart, this person should be as high as necessary and as low as possible.

Figure 1. Common Decision Rules Some noncollaborative decision rules are useful in a crisis or when stakes are low. This figure is adapted from a diagram found in Sam Kaner's Facilitator's Guide to Participatory Decision Making.

Some noncollaborative decision rules are useful in a crisis or when the stakes are very low (see Figure 1 and Table 2). A collaborative process tends to be lengthier than other methods because more players are involved, but when the stakes are high, a collaborative decision is more successful.

Two decision rules that are good strategies for medium- to high-stakes decisions: Consensus and Decision Leader Decides after Discussion (see Sam Kaner's Facilitator's Guide to Participatory Decision-Making published by New Society Publishers in 1996, and tutorial notes from Kaner's "Participatory Decision Making: Tools for Reaching Closure," given at the International Association of Facilitator's Annual Conference in Tulsa, Oklahoma in January 1997).

Consensus is a state of mutual agreement in which everyone's legitimate concerns are satisfactorily addressed. As a result, the group owns the decision, and the values of harmony and solidarity are promoted. The chief drawback of the Consensus rule is that it requires time to thoughtfully evaluate options, impact, risk and other elements. It also diffuses the power and authority of the leader.

The Decision Leader Decides after Discussion rule is a consulting style of decision making. The leader obtains relevant information from stakeholders and then makes the decision. This style of decision making is collaborative when the decision leader gets valid infor-mation along with a high degree of commitment from the stakeholders in the decision.

A Useful Tool
To be effective, the two collaborative decision rules must use a mechanism to test the degree of agreement among the group members. This mechanism must be understood and accepted by everyone.

Figure 2. Degree of Agreement Scale A useful tool is the Degree of Agreement scale where participants indicate where they fall on the four-point scale. This figure is adapted from a diagram found in Sam Kaner's Facilitator's Guide to Participatory Decision Making.

A tool I find useful is a four-point Degree of Agreement scale (Figure 2). All the participants indicate where they fall on the degree scale, indicating how strongly they agree with the proposed decision. To have consensus, everyone participating in the decision must be in the "zone of agreement," a one or two. All those who designate themselves as twos must share their concerns. This further discussion may result in modifications to the proposed decision by the group.

With Consensus, the group must continue to work on the proposed decision if there are any threes or fours. However, if the decision rule is Decision Leader Decides After Discussion, the decision leader can either choose to make their decision at this point or ask for more discussion.

When I facilitate workshops in which a decision is being made, I use this scale to check for the degree of agreement. When a group is ready to consider a specific proposal, we clarify the proposal. I then poll each person using a polling process that varies depending on how controversial the proposed decision appears to be. I might poll the group anonymously, ask everyone to simultaneously hold up a single index card, or ask members of the group to explain their positions in one minute or less.

The group repeats this process for each decision, taking one minute or less for each round. If there are any twos, I always ask those individuals to share their reservations. The process creates a group norm for decision making.

Real-World Decisions
Recently I facilitated a two-day user requirements workshop for a purchasing application at a global consumer products company. The application was being designed for use by some 120 users in 60 countries, and the participants were the IT and business team responsible for delivering the system. I began by interviewing the potential participants to gauge their needs and perspectives and to nail down the workshop's purpose. I also inspected the work products: 12 use cases representing user requirements. For each use case modeled in the workshop, the group had to decide its disposition. We had to be able to answer, at the end of the workshop, "What is the disposition of use case one?" and so on through use case 12.

Having determined the workshop's purpose, my next step was to work with the decision leader to select the decision rule. Pamela, the business project manager, was responsible for representing the needs of this customer base. She and two business analysts would test and support the application and train end users after it went live in seven months. Pamela "owned" the requirements. She obtained the funding and would continue to play this role. It was Pamela's responsibility to make the decision rule.

Pamela initially selected the Consensus rule, seeking agreement among her staff of business analysts. Because the IT participants didn't have the content knowledge or authority to fully contribute to this decision, this rule made sense, but I was concerned about the time needed to achieve consensus. I knew there was a risk that we wouldn't cover all the use cases in a single workshop. Offsetting that concern was the fact that Pamela was a subject matter expert. After she went through the modeling and reviewing activities and received input from her team, she would likely be able to make the decisions.

I told Pamela I was concerned about the time required to reach consensus, and she reconsidered. She then selected the other collaborative pattern, Decision Leader Decides after Discussion. She realized that polling her team members for their degree of agreement would give her sufficient data to make a decision.

At the beginning of the session, I explained the decision rule choice and the process and polled the group to check their degree of agreement on using it for this workshop. The participants were all ones on the scale, so we used this process for each use case. In the end, using the decision rule accelerated the flow of the session.

On another project, I facilitated a four-day workshop for a cross-functional business team. Its task was to deliver a strategy and high-level implementation plan to migrate the company's purchasing, manufacturing, and inventory applications to a standardized product and material information system. The task was to decide what migration strategy to adopt. Before the workshop, five options had been documented. The group's decision would be reviewed and ratified by an executive steering committee. The stakes were high: 140 systems, 30 sites and thousands of businesspeople were affected.

The steering committee chose Consensus as the decision rule. The participants, carefully chosen and ratified by the executive sponsor, represented all the stakeholder groups. No single person understood all the risks, benefits, and impacts of the task, but together they had the wisdom to determine the best possible strategy. In the end, they combined features of three of the options, arriving at a sixth, better migration strategy.

Here's another example. Ken, an IT project manager, asked me to facilitate a workshop for determining a release strategy for a new underwriting application. The software could be implemented by region, by product, by state or any combination. When I asked Ken about the decision rule, it became evident there was no "person in charge." A series of reorganizations and leadership changes had resulted in the project having no business sponsor. Therefore, there was no one to carry out the first step: selecting the decision rule.

Why is sponsorship so important? Asking people to participate in a decision is powerful, but it's discouraging if the decision isn't sponsored. A decision without sponsorship will fail. Sponsors ensure that the decision is supported logistically, financially and politically.

Rather than make an unsponsored decision, I suggested that Ken and his team decide who its sponsor should be and then solicit that person to act in that role. Ken and his team agreed. Rather than a two-day release strategy workshop, I facilitated a half-day sponsorship workshop. Because there was no decision leader and we needed a decision rule, I proposed that they use Consensus. I then led them through a process to decide on their decision rule, using Consensus as the default decision rule. Everyone was a one on the agreement scale.

Next, I led a brief discussion on the meaning of sponsorship and the impact of not having a sponsor. I then asked the participants to generate and analyze the sponsorship possibilities.

In less than two hours, the group converged on a recommendation for a sponsor and a supporting sponsorship organization. The session ended with the recommended sponsor, who was part of the session, stepping up to the plate in that new role. The project got back on track and was soon able to move forward with a decision on its software release strategy.

A Sense of Balance
If you make important decisions in a non-collaborative manner, you risk making poor decisions that are difficult to sustain. And without a decision rule, people are vague about when, and even whether, a decision has been made. They delay taking action, resulting in the waste of valuable time and money.

Effective collaborative teams, on the other hand, tend to make timely, high-quality decisions and successfully follow up on them. They learn from divergent perspectives, listen to each other's interests, make reasonable choices and come to closure. Good decision-making groups seek inclusive decisions that merge the best of all the options.

Perhaps just as important, if the decision turns out not to be the best one, these teams have the ability to recognize it and recover. They have learned how to balance the content of the decision with the process of arriving at it.