Decision Making and Decision Management

[article]
Summary:

Decision management is an overly formal-sounding title for an essential set of skills and processes needed by every project manager on a nontrivial effort. Project managers must be thoughtful about decisions. This doesn’t necessarily require an additional process, but it might involve a more rigorous application of the processes currently in place.

A recent consulting engagement in which I coached new project managers encouraged me to revisit the basic skills of decision-making and decision management. Decision management is an overly formal sounding title for an essential set of skills and processes needed by every project manager on a non-trivial effort. Decision management answers the following questions:

  • What decisions are we awaiting that threaten schedule delays, budget changes, or scope changes?
  • When are those decisions expected?
  • Who will make them?
  • What information will inform the decisions?
  • How will the decision results be captured for posterity?

This sounds easy enough, but as project (and organizational) size and complexity grow, an explicit mechanism to manage decisions may be valuable.

OMG, Not Another Process!
Process for processes sake is a poor idea. Before proposing any new process, a good question to ask is, “What is the bad effect of not having this process?” 

Do you recognize any of the following symptoms from your project?

  • Decisions (involving questions like “Which hardware to buy?” “Which software to buy?” and “Are we going to hire another QA analyst?”) are discussed as important, but seem to get repeatedly pushed into the future by the people who need to make them.
  • Decisions that were made months ago are continually being revisited and discussed without action.
  • People have difficulty identifying who participated in a specific decision and when the decision was made.
  • When key decision makers leave a project, some of constituencies attempt to overturn decisions of “the prior administration.”

To be clear, there may be no problem if these questions come up occasionally. We should periodically re-consider important decisions as new information emerges to avoid compounding mistakes by ignoring them, but if you are seeing a lot of this, it may be a sign that decision management is not working well on your project. This doesn’t necessarily mean you need a new process; you may already have what you need. It may mean you need to refine how you are using what you have.

We May Already Have the Mechanisms
The good news is that many projects already have developed mechanisms to manage and communicate significant decisions that are part of other project processes. Significant scope-changing decisions, for example, should be documented using the scope management or project change management processes. Project managers often use the issue management process to communicate and monitor important project decisions. Some projects make recording and communicating important decisions a part of their normal communication planning. The important thing is not what you call your decision management process, but rather that the vehicles exist to manage, record, and communicate important decisions.

Higher Standards for Decision Management on Projects  
A recent consulting engagement had me coaching a crop of new project managers, a smart group of people unfamiliar with a project leadership role. It underscored for me one of the differences between doing staff work (installing systems, providing tech support, and administering systems) and doing project work.

Staff work often involves identifying decisions that must be made, and escalating them to the person in the organization with the authority and information to make the decision. People engaged in staff work are often relieved of the burden of recording a decision or formally communicating the outcome beyond the people immediately and obviously impacted by the change. Project management requires a different orientation and sometimes higher standards for decisions.

Project orientation involves setting and managing stakeholder expectations regarding scope, schedule, and budget; this makes decision management essential. Initial project expectations are established based upon the best information available and assumptions about information not available when the project is defined. These things together—facts and our best guesses about the facts we don’t have—are the basis for project definition. Decisions generally represent a change in project facts or assumptions, or resolution of conflict we didn’t know existed when we began. As a consequence, significant project decisions will often affect schedule, budget, and scope agreements captured in the project definition or require changes to the project schedule or budget. That means we need to keep track of them.

At the end of a project, the project manager is generally asked to tell a story addressing the following questions:

  1. What did we set out to do?
  2. What did we discover along the way?
  3. What did we do and what was our final performance against expectations?
  4. What were the causes of differences between what we started out to do and what we ended up doing?

Decisions are often a vital part of the explanation required for items number two and number four, and they must be recorded to facilitate the telling of the project story.

The “Other Project Manager”
Management consultant Tim Lister is one of my heroes. He is a master at finding terse and memorable ways to capture important project truths. In one of Tim’s talks a few years ago, he made a profound observation:

“All projects have two project managers, the official PM and time. Those decisions that a PM doesn’t make promptly will often be made by time, indifferent to the project’s best interests.”

This cuts to the heart of the other side of the decision-management coin; it isn’t just recording and transmitting decisions that are important to the project, it is also managing the decisions that have yet to be made. Many decisions, if delayed, affect costs and schedule and scope. Delaying decisions beyond a point causes hardship for the project that plays out as increased schedule and budget or reduced scope and quality.

Summary
Projects and project managers must be thoughtful about decisions. This doesn’t necessarily require an additional process, but it might involve a more rigorous application of the processes currently in place. When the need for an executive or customer decision beyond the authority of the PM arises, make sure that the importance of the decision is clear and the basics (who decides, based upon what, when) are understood so that appropriate information can be provided to the decision maker to facilitate the decision, avoiding a delay based upon the project’s failure to inform. This enables timely decisions. If a decision is delayed, ensure that the consequences of the delay are clear to the decision maker to avoid later surprises.

User Comments

1 comment
Madhava Verma Dantuluri's picture

Wonderful analysis and it's always challenge to address the decison making during the adverse situations.

January 25, 2014 - 12:59am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.