Practice: Participatory Decision Making

Practice Participatory Decision Making

Objective

The objective of participatory decision making is to provide the project community with specific practices to frame, make, and analyze the myriad decisions that arise during a project.

Discussion

The lack of adequate decision-making processes in organizations is evident in a couple of quotes from clients I've worked with in the past few years .

"That one decision-gradient diagram [Figure 7.4] was the most important piece of the two-day consulting session," said a product development VP client recently.

Figure 7.4. Decision Gradient

"It's difficult to speed up development when management takes weeks to make key decisions," lamented an Irish development manager whose company executives are in Silicon Valley.

"Our project managers are like a herd of deer standing on the highway with a tractor-trailer truck bearing down on them," said one project team member. "They can't figure out which way to jump, but if they don't decide soon, we're going to get run over."

As I trek around the world of product development and project management, I'm continually amazed at how little organizations think about their decision-making processes. Many of them put time and energy into processes like time recording and virtually ignore decision making. However, in a fast-paced agile project, decision makinglike other activitiesmust be done quickly and effectively. Slow decision making, revisiting decisions again and again, over-analyzing decisions, and poor participation in the decision-making process will doom a project, as poor decisions cascade into a flood of additional decisions.

However, decision making can improve, and it can be participatory, as the GE jet engine plant in Durham, North Carolina, proves. "At GE/Durham, every decision is either an A decision, or a B decision, or a C decision," writes Charles Fishman (1999) in an article in Fast Company . "An A decision is one that the plant manager makes herself, without consulting anyone . B decisions are also made by the plant manager, but with input from the people affected. C decisionswhich make up the most common typeare made by consensus, by the people directly involved, with plenty of discussion." Using this system, the plant manager only makes 10 to 12 "A" decisions in a year and spends significant time explaining those to the staff.

The article goes on to address the very crucial issue that arises in discussing self-organizing teams :

What is the role of a plant manager in a place that manages itself? If the plant needs a manager like Sims to make just 10 decisions a year, what does she do with the bulk of her time?

She does the kinds of things that most managers talk about a lot but that they actually spend very little time on. At the operational level, her job is to keep everyone's attention focused on the goals of the plant: Make perfect engines, quickly, cheaply, safely. Strategically, the plant manager's job is to make sure that the plant as a whole is making smart decisions about talent, about time, and about opportunities for growth (Fishman 1999).

These management roles are analogous to the coaching and team development practices I discussed earlier in this chapter. Oh, and the GE/Durham plant is a model of effectiveness and efficiency. One of the critical skills workers have to learn there is how to function as part of a high-performance team.

Even authors Carl Larson and Frank LaFasto (1989), who at least recognize the importance of decision making, don't delve into how to actually improve the process. They do, however, observe, "The third set of leadership principles, and we believe the most important, clearly focus attention on the creation of a supportive decision-making climate." They also point out that achieving a goal requires change, that change requires decisions be made, and that making decisions involves risk. Without a safe environment in which team members can take risks, effective decision making will be stymied.

At its core , collaboration is about decision making. We can talk, share ideas, and debate issues, but in the final analysis decisions must be madeabout design, about features, about tradeoffs, about a host of issues. Collaboration isn't talking, it's delivering, and delivering means making decisions. A participatory decision-making process can be useful for larger groups or for two individualsthe process and the issues are the same. Furthermore, while the steps of the decision-making process may proceed less formally between two individuals than they would in a group , the emphasis on sustainable, win-win decisions based on debate and full participation remains key.

One definitional point is critical: Participatory decision making (everyone participates) is different from consensus decision making (everyone votes in favor). The latter is too slow and isn't appropriate in many project situations where the divergence of ideas and opinions would limit the effectiveness of the decision-making process. The critical element isn't consensus but sustainability: Will the team consistently implement decisions that are made? Participation leads to sustainability more efficiently and effectively than consensus. In consensus decision making everyone votes on the decision, and no decision can be implemented without a unanimous vote. In participatory decision making, team members participate in the decision process, but the project manager may actually make the decisions, or the decision is made by a preponderance of the vote.

No doubt decision making is hard, but it is made harder than necessary by poor practices. While "rational" decision making may be a fantasy, there are practices that can assist project teams in making better, implementable decisions. Three elements compose a decision process: decision framing, decision making, and decision retrospection. Framing establishes "who" gets involved in the process, while decision making establishes "how" the "whos" go about making a decision. Retrospection provides feedback into the decision-making process. As with other APM practices, decision-making practices must be implemented with the Simplify principle in mind; otherwise the team will end up with just another unwieldy set of procedures and forms.

Decision Framing

The intent of the often overused term "empowerment" is to delegate decision-making authority to lower levels of organizations by changing who makes decisions. Decision framing focuses on who gets involved in the decision process. Managers who make decisions without input from subordinates and peers make poor decisions. Engineers who make decisions without input from managers and peers make poor decisions. Who makes the decision is less important than getting the right people involved in the decision process.

However, framing involves more than "who"; it also means considering the values and principles that participants share. Without these shared values and principles, project teams will have difficulty reaching sustainable decisions. The agile values and principles articulated in earlier chapters, whether adopted verbatim or adapted for a specific organization, are vital to your decision-making process. There is a hierarchy of decision-making criteriavalues and principles, product vision, and project tradeoff matrix, as well as detailed criteria such as design parameters (e.g., usability). Teams that fail to agree on principlesexplicitlywill have problems making sustainable decisions as projects progress.

The next task in framing decisions involves identifying types of decisions that need to be made. For example, in an agile project, replanning occurs at the end of each iteration or milestone. Replanning often involves making tradeoff decisionsschedule versus cost versus features. Projects should include a defect triage decision framework, which is basically asking and answering the question, "Is this product ready to release?"

For each decision type, typical framing questions are:

• Who is impacted by the decision?
• Who needs to provide input to the decision?
• Who should be involved in the discussions about the decision?
• Who should make the decision (the product manager, the project manager, the project team, the project manager with the team, etc.)?
• What decision criteria should be used?
• How and to whom should the decision results be communicated?
• Who should review the decision?

The answers to these questions will involve several overlapping groups of individuals. For example, there may be a wide group of people impacted by the decision, but only selected individuals from those groups may be contacted for input. Everyone who provides input to a decision may not be involved in the discussions about those decisions. There are many decisions that bore project team members, and thus they don't want to be involved, while they do want to be heard on other decisions. Sorting out the various involvements should be the result of careful thinking by the team members and the project and product managers.

Team members often feel isolated from decision processes, not knowing when, why, or how decisions get made. Making decisions is only part of implementing them. Rapid, effective implementation requires a participatory process that involves the right people, with the relevant information, gathered together at the right time.

Many companies and project managers spend far more time on development processes than decision making, which brings to mind a racecar engine running on increasingly viscous sludge. Both will grind to a halt. Framing is the first step in getting the sludge out of your decision-making process.

Decision Making

In many organizations, decision making is viewed as a win-lose proposition. Participants in the process have a preconceived view of the right answer, and their approach is to argue as loudly as possible until the opposition gives up. Participatory decision making focuses on win-winor "both/and" rather than "either/or." Win-win decision making focuses on mutual understanding rather than loud posturing. This shouldn't imply a lack of heated discussion but a discussion focused on trying to understand the underlying issues rather than debating preordained positions . Participatory decision making can be contentious but civil, based on mutual trust and respect. It moves teams beyond compromise to reconceiving. Participatory decision making is a process of reconceiving a solution to a problem based on information from all team members. Compromise implies giving up one idea for another (and often results in inferior decisions); reconceiving implies a joining of ideas.

Collaboration is hard. In seemingly interminable meetings, team members often flounder in the "groan zone," author Sam Kaner's (1996) wonderful term for the time period in which meeting participants struggle to understand each other. While many people have heard of the famous team progression process "forming, storming, norming, performing" (or, more aptly at times, forming, storming , thrashing, crashing), Kaner's model consists of the divergent zone, the groan zone, and finally the converging zone.

There are two objectives against which any decision-making process must be judged. First, does the process result in the best choice given the circumstances in which the decision was made? Second, was the decision implemented? As many project managers have found out the hard way, making and implementing decisions are two different things. How many times have you encountered decisions made within the confines of a conference room that fall completely apart when the participants walk out the door? Anyone can make a decision, but effective managers grasp that implementation requires people to understand and support the decision.

A participatory decision-making process has three components : principles, framework, and practices. The fundamental principles have just been alluded to: viewing the process as a win-win process and treating all participants with respect. All collaborative practices are based on trust and respect, or perhaps more precisely, on building trust and respect. [5] Kaner's diverge-groan-converge model provides a framework for building these positive relationship qualities. In the diverge-groan-converge framework, the transition from the divergent zone to the convergent zone explains how team members move from having individual opinions to having a unified position. At first, people's ideas diverge. Even though each person wants to contribute to success and to making a quick decision, each wants to voice his or her own opinion. Everyone has a different perspective or a different experience, which brings needed diversity to the decision process but not much agreement. This groaning period takes time, time for people to speak and hear, time for them to build trust. A little extra time (it's not really extra, but it seems as if it is) taken on decision making in the early stages of a project will significantly reduce time as the project continues.

[5] The idea of building trust may seem counter to the earlier statement that managers either trust or don't trust. However, a manager can believe in trusting team members but also understand that the level of trust must be earned through actions. People are predisposed to trust or not trust, but they still want proof of that predisposition.

Convergence occurs as the individual ideas are integrated into a whole solution. Convergence, done correctly, does not necessarily mean that everyone is in complete agreement but that everyone has participated and will support the final decision. The goal is not merely agreement but "sustainable agreement"a unified position.

The transition period between divergence and convergence, the groan zone, is the time during which team members groan and complain. In the divergent zone, most group members voice their opinions to make sure the group hears their ideas. Much of this time could be considered presentation, during which members are less concerned with understanding each other than with selling their own ideas. Participants begin to groan because they are trying to understand one another, and understanding requires thought. It is relatively easy to take a position and argue for it. It is much more difficult to attempt to understand why other participants hold their opinions. Participants want to ask questions, they want to be heard, they want toparticipate. The groan zone provides a perfect description of what happens in most teams; it is a turbulent zone where innovative, creative results are generated.

One of the best tools for testing how the decision process is proceeding, and for arriving at the decision itself, is a decision gradient that replaces the familiar yes-no voting. A decision gradient, as shown in Figure 7.4, gives participants more options: in favor; OK, but with reservations ; mixed feelings; not in favor, but will commit to implement; veto. When all participants plot their responses on a line with these gradations, the entire team gets to view its collective opinion. The team can then address issues like trying to understand the person who vetoed the decision or trying to understand why so many people are clustered around "mixed feelings." Votingor actually, the discussions about why the voting was one way or anotherleads to a deeper understanding of the issues and eventually to another vote. Decision gradients make for better discussion and more effective, sustainable decisions. [6]

[6] See Kaner (1996) for more information on decision gradients.

When some person (manager, technical leader) is designated as the decision maker, a preponderance of agreement among participating team members is helpful but not essential. But when a team as a whole is the decision maker, what actions craft a sustainable decision? In many people's minds, consensus has come to mean "unanimous," and I too was using the unanimous connotation earlier in this section. But consensus has another definition that corresponds to the idea of a preponderance of agreement among participants. Intel is one company known for its attention to decision making. Intel emphasizes decision-making training for employees , and the company focuses on decision framing and decision-making on a regular basis. Intel has an engrained decision-making culture in which the phrase "disagree and commit" is often used. It means that someone might disagree with a decision, but he will commit himself to its implementation.

This nonunanimous type of consensus is built on the following premises:

• Everyone has had an opportunity to have his or her ideas heard and discussed.
• Consensus does not imply unanimous agreement, but it does mean that people understand the decision rationale.
• No one has been silenced due to fear or intimidation .
• The preponderance of the group votes in favor of the decision (or in favor with some reservations).
• No one vetoes the decision (instead, they disagree and commit).

Decisions thus reached are sustainable in ways that lead to team cohesion and positive outcomes . Arbitrary and capricious decisions, those imposed by force of will or organizational power, have the opposite effect.

An additional benefit to a participatory process such as the one just described is that as mutual understanding of the context (including the decision criteria) increases , the time required to make similar decisions decreases rapidly . For example, a defect triage team that develops a shared understanding of the relevant quality factors involved in reaching decisions will speed up its decisions over time. Conversely, teams that do not take additional time in the beginning to fully understand each other's perspective on some issue (e.g., quality) will constantly argue the same points meeting after meeting, wasting irreplaceable project time.

Different kinds of decisions require different decision criteria. Coin flipping works for what time to go to lunch . The tradeoff matrix steers high-level decisions, just as performance criteria might steer technical decisions. Release decisions might use certain quality criteria. For each kind of decision, one of the discussion topics should be the criteria to be used in making that type of decision. You may even need to go through a decision-making process to arrive at the criteria for making a decision.

Decision Retrospection

End of iteration, milestone, and project retrospectives should include time to review decisions within the context of reviewing the team's performance (which I discuss in the next chapter). However, if project retrospectives are difficult to do in general, then decision retrospectives border on the impossible , because finding whom to blame often seems more important than learning. But how do we get better at decisions unless we understand which ones worked out well and which ones didn't?

We are sometimes our own worst enemies. In the medical profession, for example, airing mistakes is especially difficult because of the threat of medical malpractice suits . Sharing and learning from decisions become severely inhibited; therefore, the same mistakes are repeated by other doctors or other hospitals because little retrospection occurs. A recent television program described an initiative in the northeastern United States in which this veil of secrecy was lifted in a concerted and collaborative effort between doctors and hospitals. Not surprisingly, problems decreased.

Still, few organizations want to examine decisions in any depth, which probably corresponds to the general lack of interest in decision making. Was an error-prone product released? Why? What were the decisions that led up to the release decision? Maybe the decision was actually a "good" one from a market perspective. If so, then the development staff needs to understand the nature of the decision, why it was made, and who was involved in the decision. Maybe the decision was based on market timing information, but the decision makers didn't listen to the developers, and the actual release was a disaster. If the disaster isn't analyzed , if the decision tradeoff of product stability versus market need analysis isn't revisited, then nothing will be learned and similar mistakes will be made in the future. On the other hand, a decision may be perceived as incorrect, but further analysis shows that it was actually the correct one given the circumstances. In this case, lack of analysis might keep us from making the same "correct" decision in the future.

Participatory decision making may spell the difference between success and failure on agile projects. Framing decisions, developing a collaborative decision-making process, and conducting decision retrospectives to learn from both success and failure are components of this practice.

Leadership and Decision Making

A good project manager has to be a visionary , a teacher, a motivator, a facilitator, and other things, but she must also be a decision maker. The same is true of chief engineers for technical issues. So the question becomes, at what point does a manager's decision making damage self-organization? First, when the team loses respect for the leader. But what causes loss of respect? The answer: when the manager begins making unilateral decisions. The more unilateral decisions, the less participation from the team, the less likely the decisions are to be effectively implemented.

Every team and situation are different, so there isn't a quantitative answer to the question of how many unilateral decisions are too many. However, even though presenting absolute numbers risks misinterpretation, I think the following guidelines may help define appropriate "levels" of management decision making that will continue to foster self-organization. For both managers and chief engineers, this rough guide is one unilateral decision every month or two, three to four decisions per month with team involvement, and then delegate the hundreds of other decisions to the team. In practice, few good managers make completely unilateral decisionsthey normally talk issues over with at least key members of their team. But occasionally there is a need to get things moving by making a unilateral decision. In that same vein, it is appropriate for project managers and chief engineers to make certain decisions with team participation, but if they are making more than three or four of these decisions per month, even with team involvement, they are probably too absorbed in the details.

Another issue related to management decision making is the leader's job of absorbing ambiguity. In fast-moving product development efforts in which key decisions must be made quickly, consensus (unanimous) decision making fails, but even participatory decision making can get mired in discussion and debate. Many product development issues, both technical and administrative, may be fuzzy and ambiguous. In these cases, once participation has evolved to a certain point, managers have to be willing to make final decisions. "Well, the information available to us isn't crystal clear, but in order to move forward with the project, we'll go in this direction."

Good leaders have earned the credibility to make these decisions. The technical staff respect the leader's judgment (based on previous actions taken), participate in the analysis and debate process, and willingly accept the decision in order to move on. The leader has absorbed the ambiguity of the situation, whereas leaving the decision to consensus would have bogged the project down in interminable debate. Good leaders know when to step in and take charge and when to encourage the team to take charge. They also know when to dig into why team decision making isn't working as it should.

Set- and Delay-Based Decision Making

If we want to build adaptive teams and products, not only do we need a participatory decision-making process, but we also need to look at criteria for decision making that encourage experimentation. Point-based engineering dominates current product development. Point-based engineering views design as a series of decisions in which each decision narrows the options for further decisions, and the product progresses in a steady fashion from a gleam in the marketer's eye to a final product.

Toyota upset this apple cart, at least as it pertains to the automotive industry's design process. Toyota's approach, set-based concurrent engineering (SBCE), provides a new insight into product design. SBCE operates on two fundamental concepts: postpone design decisions as late as possible and maintain "sets" of design solutions throughout the majority of the design process.

"SBCE assumes that reasoning and communicating about sets of ideas leads to more robust, optimized systems and greater overall efficiency than working with one idea at a time, even though the individual steps may look inefficient," write Durward K. Sobek, Allen C. Ward, and Jeffrey K. Liker (1999). Rather than converge on a design "answer," Toyota's engineers maintain sets of designs. For a particular car project, they might maintain six alternative solutions that include prototypes and mock-ups for the exhaust system design.

Unlike point requirements, set-based requirements focus on ranges or minimum constraints. So the body design group would impose a criteria "range" on the exhaust system, keeping the tolerances as broad as possible in the beginning and narrowing them over time as the car approaches manufacturing. As the body design and exhaust system designs evolve , engineers are more likely to balance subsystem optimization with overall vehicle optimization. In a point-based approach, each subsystem team has a tendency to quickly create optimized designs for its particular subsystem that are often at odds with overall system design effectiveness.

Toyota's slow narrowing of options extends even to die making. Rather than specify precise part fit, designers specify wider tolerances. The die makers themselves create the parts , see how they actually fit together, and then send the precise measurements back to the design groups to finalize the detail CAD drawings.

Engineers, whether of automobiles or computers, tend toward point-based solutionsthey analyze the problem, review the constraints, and then design "the" solution. But there are always multiple design options, and the larger the product or product family, the more likely that early design decisions will lock the team into suboptimal solutions. Maintaining multiple sets of solutions and delaying final design decisions, even though it may appear to be inefficient, may in fact be faster and more efficient in the long run. As Sobek and his coauthors observe, "Toyota considers a broader range of possible designs and delays certain decisions longer than other automotive companies do, yet has what may be the fastest and most efficient vehicle development cycles in the industry" (Sobek et al. 1999).