PM Articles > Kent McDonald > Decisions, Decisions …

Decisions, Decisions …

I am writing this particular column on Election Day in the United States. By the time you are reading it we will, hopefully, know who the next President of the United States of America is going to be. And while it’s tempting to draw lessons learned from this year’s election cycle, I would rather focus on an approach that you can use to make decisions—both on your projects, and perhaps even for whom you are going to vote. The keys:

  • Know who is going to make the decision
  • Know what information you need in order to decide
  • Know when the decision needs to be made

The approach is rather straightforward, but it does involve looking at things from a different perspective, one that can be uncomfortable for some. Let’s take a look at how it works in practice.

It’s a Judgment Call

Recently I worked on a project at a regional insurance company to implement a specialized call center. We were partnering with a small company that specialized in running these types of call centers. They were very good at what they did, but they were small, and our contract was considerably larger than any they had before; our volume stressed their technical capabilities, especially with respect to transferring data back and forth for operational and analytical purposes.

Some on our team were concerned that the vendor would not be able to complete the necessary integration work in time, which meant that while they could operate the service, they would not be able to provide sufficient analytical data. We had a decision to make. We could trust the vendor to deliver the necessary functionality by the due date and be in a sad state if that did not happen, or we could add additional work internally to produce the necessary analytical data. We were still not sure if we could even do the work internally in the desired time frame. We were still three months out from the targeted implementation point, but there was a burning desire to make a decision NOW!

Did we really need to make the decision right then? Could we trust the vendor to deliver? Are there ways to gather more information to allow us to make a more informed decision?

Know Who is Going to Make the Decision

This may seem like obvious advice, but I have seen too many situations where teams flounder because they do not have a clear idea of just who should be making the decision, or because the most appropriate person is not the one making the decision. To avoid decision confusion, determine who is going to decide before any decisions become apparent. It is a lot easier for people to step up to that responsibility when the spotlight is not on, and knowing who needs to make the decision prevents a lot of the axle-wrapping that can occur when a decision comes up. Knowing who will make the decision also results in a quicker determination of the other key points—what information you need and when you have to decide.

It would be awfully presumptuous of me to throw out this idea without some suggestions on how to select the appropriate decision-maker(s). I have found that a mental shift in the concept of roles is helpful here. Most project teams view roles as definition of who does what. This view of roles can be quite limiting , especially if the team members have the capability of helping out with tasks outside of their narrowly defined roles when necessary. I prefer to think of roles as defining who decides what. I fill the role of Project Manager on many projects, but I often pitch in to help with analysis, testing, and even a little bit of development from time to time. When I take on these other tasks, I always check my work with the team’s expert in that particular field. I do some tasks to help avoid a bottleneck, but the expert makes the final decision on whether the work I produce is appropriate.

In the call center example, the team thought it was best to make the decision in a collaborative manner, as is appropriate for design or implementation approaches. I find it useful to make those decisions collectively as often as possible so that all viewpoints can be considered and everyone can buy into the final decision. Of course, not all decisions are applicable to a collaborative approach, so determine which ones are and are not ahead of time. That way there is no resentment when select individuals are making decisions in some cases.

Know What Information You Need in Order to Decide

I like to think I make informed decisions, but in order to actually do that, I need a handle on what information is most appropriate to the decision at hand. When I know I have a decision to make, I try to always understand the relevant pieces of information necessary to make the best decision. In the case of the Presidential election, some criteria I factor in include the candidate’s leadership style, their position on certain issues, their background, and their level of experience.

For personal decisions such as voting, the criteria depend on the person. In the case of project related decisions, the criteria depend on the nature of the project and the team. One helpful technique I have found is to establish a value model for the project. This model attempts to capture the various inputs into a project that have some sort of impact on the value that project contributes to the organization. Those inputs can be concisely summed up as:

  • Purpose
  • Considerations
  • Costs
  • Benefits

The true usefulness of the value model arises from the discussions that occur to create it. Framing the information in this fashion gives the team the opportunity to discuss the truly important factors that impact the project’s success, as measured by its contribution of value to the organization.

In the case of the call center, the primary information we were seeking was a set of considerations. What was the vendor’s capability to deliver on their commitments? When did we really need to be able to produce reports? Did we have the capability to provide the analytical functionality if the vendor didn’t? What was the cost impact of the vendor providing that functionality versus the team building it internally? We knew that once we had answers to most of those questions, we would be much better positioned to make a rational decision.

Know When the Decision Needs to be Made

I think this is the most important piece of advice regarding decisions, and it is also the hardest to follow on a regular basis. People generally abhor uncertainty, which leads them to make decisions quickly, even without all of the necessary information, in the attempt to reduce the uncertainty they face. I follow that approach when it comes to booking airfares, thinking that once I know for sure I am going somewhere, I am better off to purchase the ticket as quickly as possible. Sometimes it works out; other times I am the victim of random schedule changes.

If you know what information you need, and you know what factors influence when you absolutely have to make a decision, you can defer your decision up to that point in order to gather as much information as possible. Just remember that you need to define when you will make the decision instead of just deferring it to an indeterminate time.

In the case of the call center, we met as a team and chose to exercise a third option. We deferred the final decision on who was going to prepare the analytical data until closer to the delivery date. To get to that date, we walked back from the final implementation date the number of weeks that we thought we would need to implement something if the vendor could not. We then compared that date to the vendor’s committed timeline, and we determined that we would have a fairly good handle on the vendor’s capability by that point. We used the intermediate time to gather confidence in the vendor’s ability to deliver and to also prepare for doing the work ourselves if we had to. And while we hadn’t made a decision when we had the urge to, we were able to forge ahead knowing that we would be well positioned to act regardless of what happened.

The vendor was very capable of delivering on their commitments, and we found that by deferring our commitment to a particular design approach, we saved both time and money. The concerns about the vendor’s ability to deliver were unfounded, but we were comfortable in our ability to mitigate that risk had it come to fruition.

A Closing Thought

I should note that I was able to write this article on Election Day because I did not have to stand in line at the polling place. I chose to vote early, primarily because I felt that I had enough information to make an informed decision, and the impact of additional information would not outweigh the time I saved by voting early. That was a good choice because this is shaping up to be quite a busy day. I knew that I was the one making this decision, I knew the information I needed in order to make that decision, I had that information, and while I had until today to make that decision, I judged that no value would be gained from waiting. This just goes to show you that you can decide early, as long as you know why.

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.