PM Articles > Geof Lory > Decide to Decide

Decide to Decide

by Geof Lory

The ability to make solid decisions, both business and technical, is one of the most important skills teams and organizations can cultivate. On every project, we make countless decisions -- some small, some with far reaching impact. While many different decision making styles and protocols can be used to fit varying situations, high performing agile teams are characterized by a collaborative and speedy decision making process even when dealing with ambiguity.

Before talking about increasing the quality of decision-making, we need to set the stage appropriately: All decisions are inherently made within the context of the project goals and objectives. Unless the team has a clear and common vision with commonly understood goals and objectives, no specific style, protocol, or process will enable meaningful decision-making. Shooting in the dark is never improved by a better gun. If this context isn't in place on your project, you can stop reading now.

So, assuming a defined line of sight, let's talk decision making.

Today's projects, especially those most conducive to agile methods, require an increasing number of decisions to be made and made quickly. A lot of attention is focused on the process of deciding, but we need to remember that the quality of a decision is affected by the response latency: the elapsed time between some project event occurring and seeing the consequences of the related project action taken. During this process, decisions are identified, analyzed, made and acted on so the team can get feedback on the result of the decision. And then the process starts all over again. The point is, more and more we are called to make sensible decisions in a business climate of growing uncertainty and change, so speed to decision has to be part of the equation.

In his book, Agile Software Development: The Cooperative Game, Alistair Cockburn equates the "unvalidated decisions" to the Work In Process (WIP) inventory in an assembly line. Too much WIP creates backlogs and bottlenecks, particularly at points of transition. Those decisions stuck in the pipe become excess inventory or "ambiguity sludge" that slows a project down. Making decisions clears away the sludge and smoothes out the transitions, improving throughput. So any project would do well to reduce the Decisions In Process (DIP) by addressing them when they first manifest themselves.

However, a balancing thought, presented by Cockburn in the same book, is the concept of making decisions at the Latest Responsible Moment (LRM). The basic idea of the LRM is that in order to deal with the decision uncertainty, avoid making decisions until just before it would become irresponsible (for cost or delivery reasons) not to make them. Or to put it another way, don't make decisions you don't yet need to make if the result will be to undesirably constrain your options; but do be ready to make them when it's dangerous to wait or it is necessary for subsequent decisions.

Keeping too many decisions open until the hypothetical Latest Responsible Moment will naturally increase the number of Decisions In Process. This can create decision gridlock, where the dependencies become circular or there are just too many decisions to keep track of. The weight, complexity, and volume of the Decisions In Process disrupt team flow and project throughput. The trick is balancing the Decisions In Process against the desire to wait until the Latest Responsible Moment. The right balance will improve decision quality and project progress against a backdrop of uncertainty. However, balancing is something most teams and organizations struggle with because balancing requires a continuous process of decision making. It's a catch-22 they try to address with a process, but no process will solve this.

This lack of movement is often misdiagnosed as "analysis paralysis," but I think something deeper is at play here: personal safety. When there is excessive latency in the data gathering and analysis stage of decision making, it may be because it appears to be the safe place. However, this is really a false sense of security, because to avoid making a decision is to decide by default. Either way, the impact increases response latency and inhibits project progress.

Excessive planning and an obsession with prediction at an individual, team, or organizational level is a misguided approach to dealing with the unavoidable uncertainty. A better approach would be to get comfortable with the balance of reducing DIP while allowing for LRM decisions. The balance of project DIP requires the same attention that project WIP gets. Balance the bottlenecks from the backlog of unvalidated decisions against the benefit of waiting until the latest responsible moment. The only way I know how to do this is through practice and reflection, or maybe more appropriately, trial and error.

As an agile project manager, my job is rarely to make decisions for the team -- probably heresy to most project managers, or at least their defined job description. More often, I help the team understand the decisions that are within their purview and then facilitate the balance of urgency and risk during the data capture and analysis stage, while applying forward momentum. The goal is to make the best decision in the most expeditious way. So, the standard I use with my teams is, "Can we make this decision NOW and safely move forward?" Correctness and certainty are not the primary criteria.

The summer before each of the girls started their freshman year in high school, I offered them the option to redecorate their bedroom. Within a given budget, they could have whatever colors, carpet, etc. they wanted, so long as they made all the decisions and made them in a timeframe that allowed us to complete the project before school started. It was an interesting exercise that resulted in ceilings with stars, purple walls, a honeycomb wall display for novelties, and a bead door curtain. Not only did it teach them to make timely decisions (I won't judge the quality of the decisions), but it also allowed them to live with the consequences of their decisions, every day for 4 years. Now they are looking at houses. It will be a challenge for me to be as accommodating, but I'll certainly try.

Now that both girls are out on their own, we are remodeling the house. This time, my wife gets to make all the decisions. Of course, I'll help a little, just to keep forward progress.

Related Links
Decisions, Decisions ..., by Kent McDonald
Postponing a decision isn't always procrastination. Sometimes it's the best call.

Release Decision Process Guidelines
Guidelines for typical processes that can be used near the end of a project to systematically review open issues and determine which ones must be corrected before the project deliverable(s) can be released and the project considered complete.

Project Alternatives Tradeoff Table 
A table format that gives your team a concise way to document, analyze, and communicate the alternatives you are considering for scope and features.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.