Every decision-making group should first decide how they will arrive at their conclusions by selecting appropriate decision rules.
Image by Gerd Altmann from Pixabay
I recently was a member of a team of nine people addressing a particular technical topic. The participants were all well-known and highly respected members of their professional community. Over multiple online meetings and dozens of emails spanning several weeks, the group had considerable difficulty reaching closure on several issues. We had overlooked an important step during our forming stage: deciding how the group would reach decisions. That oversight led to excessive iterations on important points, unnecessary communications, wasted time, circular discussions that never reached conclusions, and considerable frustration.
Decisions, Decisions
Every project faces a continuous stream of decisions large and small. Individual team members can make many decisions locally and informally; other issues have a far broader impact. Making a considered decision about an issue often demands obtaining input from multiple sources, having appropriate stakeholders assess the options, and communicating the outcome—and the reasons for it—to all affected communities. Each such group must decide how to decide.
Some organizations—and individuals—are better at making decisions than others. I used to work at a company in which decision-making was sluggish because no one wanted anybody to be uncomfortable with the outcome. That’s not practical. Someone must choose among the options and set directions so that everyone can work toward the shared objectives. It was frustrating to deal with managers who vacillated, never reaching closure on issues that were appropriate for their level. I had more respect for managers who would make a decision, even if I didn’t always agree with it.
Each team needs to determine who the decision makers will be for various issues. The initiative’s leaders should do this before the group confronts their first significant decision. Identifying the decision makers ensures that decisions can be made at the lowest possible level. Issues are resolved more quickly when decisions are made locally than when small matters are escalated to a higher level.
Each group also should agree upon how they will reach their conclusions—that is, which decision rule or rules they’ll apply—and the path forward if they’re unable to resolve an issue.
Who Makes the Call?
The right people to make each category of decision depends on the situation. Let’s use the requirements for a software project as an example. Major scope issues that affect schedules, resources, and existing commitments will involve senior managers or executives. Those managers could be in the developing organization, a customer organization, marketing, or combinations of those.
Even a single requirement change could have a big ripple effect if it forces revisions to multiple interconnected elements, as in a complex product that has both software and hardware components. Representatives from all the affected components need to know about the decision outcome, even if they don’t all participate in making it.
Identifying the decision makers for requirements issues is a part of stakeholder analysis. Input from those stakeholders whose interests align most closely with the project’s business objectives, such as favored user classes, should carry the most weight. Stakeholders who impose constraints—including scope, resource, regulatory, legal, business policy, or technical restrictions—might override functionality requests from other groups that conflict with the constraints. Agreeing on which stakeholders contribute most heavily to which important decisions helps the group reach conclusions more quickly and perhaps with less rancor.
Each decision-making group should identify a decision leader to coordinate their activities. The idea is not to add bureaucratic overhead, but rather to provide clear lines of responsibility, authority, and accountability. A group of people might think they have the authority to make decisions about a certain range of issues. However, if someone else can override their choices, then, in effect, that group is merely an advisory body; the other “someone” is the ultimate decision maker. The decision leader makes all those roles and responsibilities clear to avoid delays, uncertainty, revisited decisions, and hard feelings.
One large project, for which I was the lead business analyst, assembled a team with representatives from four user classes: our product champions. The largest user class required additional representatives from several subgroups to cover their diversity of needs. When requests from the subgroups didn’t agree, the product champion for that overall user class was fully empowered to make the choice. And he did! The other participants respected the product champion’s experience, wisdom, and conclusions. Having a few carefully selected and empowered user representatives who could make requirements decisions on behalf of their respective communities made life much easier for our three business analysts.
How Do They Decide?
Too often, when people begin to collaborate on some initiative, they don’t discuss how they’re going to work together. An important—and sometimes adversarial—aspect of collaboration is making high-impact decisions that influence the project’s direction. When I began my first experience coauthoring a book, my coauthor and I spent a lot of time planning how we would work together, including how we’d resolve conflicts regarding how to handle a particular topic. Those involved with every multiperson activity should have this same discussion before they encounter their first conflict.
The objective of all decision-making is to reach closure on issues expeditiously and respectfully based on accurate information, thoughtful analysis, and honest negotiation. The process for making a decision is called a decision rule. There are numerous possible decision rules, including these:
Unanimous Vote. The participants vote on the options and all must vote the same way to resolve the issue. It can be time-consuming, and sometimes impossible, to lead a group of people with diverse interests to all agree on a given outcome. If achieved, unanimity provides the strongest group commitment to the decision.
Consensus. All participants agree that they can live with the group’s decision, although they may vary in their commitment to it and their comfort level with it. Consensus is not as strong an agreement as unanimous voting. Reaching a consensus often requires considerable discussion and compromise. It takes longer than a simple vote, but the consensus-building process achieves more solid buy-in to significant decisions.
Plurality Vote. The decision makers vote on the options. The option that receives the most votes is selected as the decision. Plurality (sometimes called majority) voting is most appropriate for low-impact decisions that have several clear options.
Decision Leader Decides. A single individual can make decisions more quickly than a group can. Depending on the decision leader’s knowledge and expertise regarding the issue, the leader can either solicit input from others or reach a conclusion on their own. Soliciting others’ input is more collaborative and promotes stronger commitment to the outcome by those whom the decision affects. If people feel that their voice was not heard before the decision leader set the direction, they’ll be less satisfied with the result.
Delegation. The leader appoints someone else who has the appropriate knowledge to decide. The leader should not use delegation to avoid responsibility for whatever course of action the delegate chooses. Delegating the decision to someone else demonstrates trust in the delegate’s experience and judgment. However, if the decision leader overrides the delegate’s decision, that undermines the trust and effectively reverts to the Decision Leader Decides rule.
No single decision rule applies universally to all situations; there’s no “correct” rule. Nonetheless, every group that must make decisions should agree on its process—and then follow it.
What Happens Following the Decision?
The most important outputs from any meeting or discussion are action items to pursue, issues to address, and decisions that were made. Decisions have a way of resurfacing when someone down the road isn’t aware of the outcome, doesn’t agree with it, or doesn’t understand why it was made. The team should record its significant decisions along with the rationale behind each one. This record makes the decision outcome available to others who weren’t involved in the discussion. The team should discuss how to justify the decision to others who might challenge it.
The results of nonlocal decisions also need to be communicated to those whom the decision affects. Without clear and timely communication, team members might work on activities that were canceled or deferred, misunderstand priorities, or otherwise work at cross-purposes. When project participants understand the reasoning behind significant decisions, they can collaborate better toward common ends.
Author: Karl Wiegers
This article is adapted from Software Requirements Essentials: Core Practices for Successful Business Analysis by Karl Wiegers and Candase Hokanson. Karl is the author of numerous books on software development and other topics, including Software Requirements (with Joy Beatty), Software Development Pearls, and The Thoughtless Design of Everyday Things. Candase is a business architect at ArgonDigital. She has written numerous articles on best practices in requirements management and agile product ownership.