Everything you do every day is a kind of decision: what time to wake up, what to eat for breakfast, and who to talk to first at work. We don't often think of these as decisions because the consequences are so small, but we are always making choices. We all have our own natural judgments for which decisions in our lives demand more consideration, and the same kind of logic applies to project management decisions. Some choices, like hiring/firing employees or defining goals, will have ramifications that last for months or years. Because these decisions will have a longer and deeper impact, it makes sense to spend more time considering the choices and thinking through their different tradeoffs. Logically, smaller or less-important decisions deserve less energy.
So, the first part of decision-making is to determine the significance of the decision at hand. Much of the time, we do this instinctively; we respond to the issue and use our personal judgment. Am I confident that I can make a good decision on the spot, or do I need more time for this? It often takes only a few moments to sort this out. However, this is precisely where many of us run into trouble. Those instincts might be guided by the right or wrong factors. Without taking the time, at least now and then, to break it down and evaluate the pieces that lead to that judgment, we don't really know what biases and assumptions might be driving our thinking (e.g., desiring a promotion or protecting a preferred feature).
With that in mind, here are some core questions to consider when evaluating a decision. This list can be used at the moment to help size up a specific decision, or as a way to re-evaluate your high-level criteria for sizing up decisions.
What is the core problem for the decision?
Decisions often arise in response to new information, and the initial way the issue is raised focuses on the acute and narrow aspects of the problem. So, the first thing is to ask probing questions and get down to the real decision that needs to be made. For example, the problem might be defined initially as "We don't have time to fix all 50 known bugs we've found," but the real issue is probably "We have no criteria for how to prioritize bugs." Redefining the problem, and the decision, into a more useful form, goes a long way toward improving decision quality. Being patient and calm in response to a seemingly urgent issue generally helps to make this happen. Ask questions like: What is the cause of this problem? Is it isolated or will it impact other areas? Whose problem is it? Which goals in the vision doesn't it put at risk? Did we already make this decision in the spec or vision, and if so, do we have good reasons to reconsider it now?
What is the potential impact of this decision on the project?
A big decision, such as the direction of the vision or the technology to use, will impact the entire project. A small decision, such as what time to have a meeting or what the agenda should be, will impact a small number of people in a limited way. If it's a long-term decision, and the impact is deep, patience and rigor are required. If it's a short-term decision with shallow impact, go for speed and clarity, based on a clear sense of the strategic decisions made in the vision. Generally, it's best to make big decisions early on or in a given phase of a project, so they can be made with patient thought and consideration, instead of when the time is running out.
What’s the impact if you’re wrong?
If the impact is small or negligible, then there isn't much to lose. However, this doesn't mean you should start flipping coins. For aspects of projects such as usability or reliability, quality comes from many small decisions being aligned with each other. The phrase "death by thousands" comes from this situation, where it's not one big mistake that gets you; it's the many tiny ones. So, you must at least consider whether the choice is truly isolated. If it isn't, it's best to try and make several choices at once. For example, either follow the same UI design guidelines on all pages, re-factor all the code that uses the same API, or cut those features completely. Get as much mileage as possible out of each decision you make.
What is the window of opportunity?
If the building is on fire, no matter how complex choosing your route of escape might be, there is only a set amount of time that your decision will matter. If you wait too long to make the decision, it will be made for you; routes will close and all options will go away eventually. The way the universe works is that big decisions don't necessarily come with greater amounts of time to make them. Sometimes, you have to make tough strategic decisions quickly because of the limited window of opportunity you have. And sometimes, the speed of making a decision is more important than the quality of the decision itself.
Have we made this kind of decision before?
There is no shame in admitting ignorance: it generally takes courage to do so. If you're working on anything difficult or cutting edge, there will be times when you have no idea how to do something. Don't hide this (unless you're choosing speed over quality for the decision in question), or let anyone else hide it. Instead, identify that you think the team, or yourself, is inexperienced with this kind of choice and might need outside help, or more time, to think through the problem. If a leader or manager admits to ignorance, she makes it OK for everyone else in the room to do the same. Suddenly, decision making for the entire team will improve dramatically because people are finally being honest.
Should you be making this decision – who is the expert?
Just because someone asks you to decide something doesn't mean you're the best person to make the call. You are better at some kinds of decisions than others, so don't rely on your own decision-making limitations. Project managers are often seen as local experts: marketing sees the PM as the technical expert, and engineering sees the PM as a business expert.
But in reality, the PM may be closer to a jack-of-all-trades (and master of none). Never be afraid to pick up the phone and call the people who know more than you do about the issue at hand. At least ask for their consultation and bring them into the discussion. Consider delegating the choice entirely to them; ask whether they think it's their call to make, or yours. If the relationship is good, it might be best to make the decision collaboratively, although this often requires the most time for both parties.
Whose approval do we need and what feedback do we want before proceeding?
The larger the organization, the more overhead costs there are around decisions. A seemingly trivial decision can become complex when the politics and desires of stakeholders and partner organizations come into play. A good test of your authority is how often trivial decisions require approvals or the formation of committees. The more processes there are around decisions, the more you must work through influence rather than decree. There are political costs to decisions that have nothing to do with technology, business, or customer considerations, and the impact of a decision includes them.