Software Development Online http://www.sdmagazine.com/articles/2001/0101/0101h/0101h.htm?topic=ppm

 

Decide How to Decide — Ellen Gottesdiener, January 2001

Half the job of decision-making is deciding how to decide. Here's how to use this collaboration pattern to make successful decisions.

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 (Excel Chart)

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).

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,"

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 information 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.

A tool I find useful is a four-point Degree of Agreement scale (Figure 1). 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.

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.

Figure 1 - Four-point Degree of Agreement Scale 

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 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.

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.

 Collaboration Patterns

How you make a decision can be more crucial than the decision itself.

A pattern is a description of a known solution to a specific type of problem. It documents a core insight or instructive information, so people can solve problems quickly and effectively. The software community uses patterns largely to solve problems related to software architecture and design, and, more recently, to design software development processes and organizations.

Various types of patterns are applied to software development (see hillside.net/patterns/patterns.html).

Design patterns address the structure and behavior of software infrastructure, or the solution domain. Analysis patterns address the structure and behavior of the business, or the problem domain. Cognitive patterns describe the thinking and reasoning processes of experts. Process patterns describe techniques, actions, and tasks for developing software. Organizational patterns describe the structure and practices of human organizations.

Collaboration patterns, the focus of this article, are techniques, behaviors, and activities for people who share a common goal of working together in a group. Collaboration patterns are useful for software projects because they exploit the synergy and productivity of IT teams, customers and users acting in tandem. They exploit diverse points of view, help build and maintain group norms, foster trust, and help teams deliver quality products. Some uses include the following. 

·         Eliciting and validating requirements

·         Verifying work products

·         Solving problems

·         Making decisions

·         Building teams

·         Analyzing models

·         Selecting technologies

·         Creating work plans

·         Prioritizing requirements

·         Generating ideas

·         Designing an organization

Other collaboration patterns I use include the Sieve; Expand then Contract; Wall of Wonder; Multi-Model; Iterate the Multi-Model; Divide, Conquer, Correct, Collect; and Self-Reflect. Look for future Software Development articles discussing these patterns.