Structuring Your Decision Making: The PrOACT Decision Framework

Let me start with a confession: I can be sadly indecisive. This includes spending way too long deciding which candy bar to pick out at the gas station. It's even worse when I'm deciding something of importance – like my wife and I's years-long decision about whether to buy a different house. 

But sometimes weaknesses can result in good outcomes. In this case, it led me to discover a decision-making framework that – although it doesn't decide for you – helps you focus on the most relevant considerations as you make your decision. Also, by providing a structure to the decision-making process, it lessens the chance you'll be influenced by common decision-making errors that result when we rely merely on our intuitive thinking.

The framework I discovered is called PrOACT. It was designed to improve business decisions, but it is equally relevant to personal decisions. It was created by three highly renowned professors who do work in the areas of decision making, negotiation, and management. They've detailed the process in their book Smart Choices: A Practical Guide to Making Better Decisions. PrOACT has been tried and tested successfully as a decision framework within numerous organizations, including for over 20 years within BC Hydro – the 3rd largest electric utility in Canada – and the United States National Fish and Wildlife Service. 

The PrOACT model

So, what is the PrOACT model?  It consists of the following components:

1. Problem
2. Objectives
3. Alternatives
4. Consequences
5. Tradeoffs

Typically, each of these components is a step in the decision-making process. You'll first determine what the problem is that you're making a decision about, then you'll consider your objectives, then alternatives, etc.

Although the components are usually worked through in this order, it doesn't have to be a linear process. The framework allows for iteration, going back to an earlier step to modify a conclusion when new information or reasoning identifies better ways of thinking about a step. 

One benefit of PrOACT is that it can be used in decision-making scenarios of various complexity, importance, and urgency. Each step can be gone through quickly or slowly – depending on the importance and urgency of the decision.

However – because we frequently have to make in-the-moment decisions, we often don't have the time to go through the entire process. But even if we don't have time to do so, PrOACT can still be helpful. By being aware of the components of a good decision, we may more easily identify when there is a flaw in our quick decision thinking.

Let's look at each of the steps in order. As we do so, we'll work through a fictitious example of someone deciding how to respond to a new software feature request from a client. We'll see how we can apply the PrOACT framework to the decision.

Problem

Most often we realize we need to make a decision when a problem arises. The aim of this step is to clarify the exact nature of the decision that needs to be made in response to the problem. Often this process is called "framing" the decision – making sure it is understood from the most helpful perspective. 

The outcome of this step is that you will have a definition of your decision problem. It will look something like this:

• I (or we) need to decide ___________________________.

It can be tempting to complete this step quickly. After all, if you're making a decision, it's presumably because you've already identified a problem. So, it seems that the work is just to write down the problem that's already been identified in your head.

But frequently it's not that simple. 

For example, suppose your client asks you to provide a new feature in your existing application, and they tell you they need it completed within twelve weeks. You consider the size of your small delivery team and realize there's no way you can fulfill the request on top of the work you already have in that time. So, you might think the decision definition would be:

• We need to decide how to increase the size of our delivery team.

But notice this has implicitly precluded other alternatives. Providing a software feature quicker can be accomplished in various ways: setting aside current feature work, using a third-party solution, etc.

In coming up with the decision definition, you don't want to have as narrow of a definition as we just saw – because it will unnecessarily rule out various options. On the other hand, you don't want it to be too broad, leading you to consider options that aren't relevant or practical.

Coming up with the problem definition is extremely important. It will keep you from finding a solution to the wrong problem. 

In Smart Choices, the authors write: 

• "A good solution to a well-posed decision problem is almost always a smarter choice than an excellent solution to a poorly posed one." (16)

A problem definition is perhaps especially important when making a group decision, as it helps ensure that everyone is trying to find a solution to the same problem.

For the sake of our example scenario, let's suppose you settled on this decision definition:

• We need to decide how to deliver the requested software feature in three months.

Objectives

This step is concerned with identifying what it is you care about as you make your decision, and then setting the attainment of them as your objectives. This is essentially determining what is valuable and important relative to your decision. What is it that you're wanting to promote – or perhaps prevent – with your decision?

To take a simple scenario, imagine deciding what to eat for dinner. Things people typically value around that decision are enjoying the food, not spending too much money, and not spending too much time. Those values then can become objectives by converting them to a phrase composed of a verb and an object. So the above values would become the following objectives: enjoy food, minimize cost, save time. Those objectives will affect what kind of food you'll eat, whether you'll eat at home or a restaurant, and potentially other factors.

Frequently people skip over the objectives step and jump straight into coming up with possible solutions – what we're calling 'alternatives.' The problem with this is that it is getting the cart before the horse. Solutions are a means to an end. Before we come up with the means, it makes sense to determine first what they are a means to.

Once you've come up with your objectives, it's time to identify "attributes" for each. Attributes are the way we will measure to what degree each objective is being met. For example, for the dinner decision, if one objective is to minimize cost, the attribute might be "cost in dollars."

Defining attributes is not always easy, but it's helpful to a successful decision. If you don't know how to measure your objectives – the goals of your decision – how can you know whether your possible solutions are going to help achieve them? Sometimes it takes more time, effort, and creativity to come up with good attributes.

Let's go back to the software feature request. What might the objectives be? Obviously, this will depend in large part on the needs of the client, so we'll just speculate here. As was stipulated above, the decision definition is:

• We need to decide how to deliver the requested software feature in three months.

What things do you think the team will care about as they make their decision? One possible list – converted into objectives and their attributes-- is the following:

I've limited the list to four just for the sake of example. But other values could be listed: testable code, customizable code, secure software, etc. Within agile software delivery, the delivery principles might frequently make such a list.

Alternatives

Now that we have our objectives in hand, we can work to come up with various possibilities for meeting those objectives. The PrOACT model calls these "alternatives." We might more often call them options or possible solutions.

Having come up with the objectives first we will be in a better position to brainstorm good alternatives. First, as we brainstorm, we will have our goals in mind. We will effectively be asking, what is a good means to achieving those various goals? Second, since we defined our attributes, we will have the measurement in mind that you are trying to affect.

Continuing with the software feature request, given that we've determined our objectives, we can now work to figure out possible alternatives.

How to brainstorm is outside the scope of this article, but I want to share one tip that is made possible by the PrOACT model. The goal is to come up with better and more varied alternatives. Keeney suggests that when you have multiple objectives, consider each objective independently and ask, what solution would optimize for that objective? Doing so may trigger some ideas you wouldn't think of if you were also trying to satisfy other objectives. Once you do that for all objectives, then step back and try to figure out whether you can incorporate those various ideas – likely with some modifications.

Suppose that after brainstorming, we came up with three seemingly viable solutions:

1. Set aside current feature work
2. Use a third-party software solution
3. Increase the size of the team

We now need to figure out which of these alternatives we should select.

Consequences

In the PrOACT model, after identifying possible alternatives, we next step back and ask what the consequences of each alternative are for each of the objectives we identified earlier. And, since we also defined the attributes that we're going to measure the objectives by, we will be concerned with how those consequences of the alternatives will impact those measurements. 

For displaying the information, an easy way to do this is to create a spreadsheet that lists the alternatives, objectives and attributes.

To decide which of the alternatives we should go with, we need to figure out which one is most likely to help us best achieve our various objectives. To do that, we'll consider what the consequences are of each alternative relative to each of the four objectives and ask, what is the consequence of the alternative for that objective?

An easy way to display the information we come up with is a table that lists the alternatives, objectives and attributes.

After deliberation, research, etc., that table might turn out like this:

You may be concerned – and rightly so – that it can be hard, if not impossible, to determine the consequences of alternatives as precisely as has been shown above. I'll address that concern later in the Q&A section. 

If in looking at the consequences table you can identify an alternative that is better – or at least equal to – all other alternatives for each of the objectives, then it is clearly the best alternative. You can be confident in deciding upon it as the solution to your originally stated problem. So, you could stop here and not proceed to the "Tradeoffs" step.

But frequently it's not that easy. Often one alternative will be better relative to some objectives, but worse for others. So, what do we do?

Tradeoffs

When we're faced with no clear winner, we need to consider tradeoffs. We need to figure out which alternative is overall better, even if it does not satisfy some objectives as well as other alternatives. 

To start, you may want to determine if any alternatives can be easily eliminated. Narrowing down the list simplifies the remaining process of comparing the potential alternatives. 

Find any alternatives which are largely worse off than the other alternatives and have little to no upside. They can safely be removed as possible best alternatives. 

For example, suppose that according to the business needs, the on-time delivery of the feature was significantly more important than any of the other objectives. In that case, the alternative "Set aside current feature work" might be clearly inferior to the others, since the expected time to complete the feature would be past the deadline. 

Now we only have two alternatives left. Which alternative is best will depend on the needs of the client. If money isn't a major factor to the client in this context, they may be willing to go with the third-party solution since it will get the feature completed the quickest. But, if they're cash-strapped, they may decide the longer delay is worth it.

There may not be a purely data-backed best alternative. As this example highlights, the PrOACT model doesn't automatically determine the best alternative. Most of the time you will have to rely on your intuition about which objectives are most important (and how much more important they are).

There are other strategies for further evaluating alternatives relative to their objectives, which can further lessen the reliance upon intuition. In particular, the PrOACT model includes guidance on how to deal with uncertainty, risk, and linked decisions. But those are beyond the scope of this article.

Hopefully, the core elements of PrOACT are enough to help you think more clearly and effectively about any significant decisions you need to make. And, for less important decisions, even if you don't formally progress through the individual steps, being aware of the components of a good decision can help you make better choices intuitively.

For more on PrOACT:

• Smart Choices: A Practical Guide to Making Better Decisions, by John Hammond, Ralph Keeney and Howard Raiffa
  • The book on which this article is based.
• http://www.structureddecisionmaking.org 
  • A website that provides detailed instructions and tips on how to use PrOACT (what it calls "Structured Decision Making").
  • The people responsible for the website use SDM in the context of making decisions around natural resource management, but the instructions are largely independent of that content.

Oh, and about that years-long house decision I mentioned at the beginning of this article. My wife and I decided on and bought a new house in July of 2021. I can't say that PrOACT was responsible for the decision. But it did help in that I had a consequences table of a handful of alternatives, including our current house, several houses we had previously considered, and the house we were thinking about buying. I could better visualize what the new house had to offer relative to our objectives and the other houses we had considered. 

Q&A

Q: Determining the consequences for various objectives is very fuzzy and hard to determine accurately. So, is PrOACT really practical?

A: Determining consequences can be fuzzy and indeterminate. But, this isn't a problem caused by PrOACT. It's a problem exposed by PrOACT. When we don't write down our objectives and the attributes by which we're measuring them, it makes it a lot easier to ignore or not even see the fuzziness. 

PrOACT's exposure of the fuzziness has two benefits:

1. We can recognize a need to discover a clearer and more determinate objective or attribute by which to assess our decision better.
2. It helps us identify unknowns – enabling us to be more honest about the certainty of our decision.

Q: Is there a risk that too many objectives will be identified and that it will become unmanageable?

A: Yes, that is a risk. But again, it's not a problem with PrOACT, it's a problem exposed by it. If you didn't use PrOACT and made your decision without considering many of those objectives, you would have made a decision that neglected to consider things you value. 

There are various strategies for dealing with a long list of objectives. One I'll mention is to decide on what seem to be the top 6 – 10 objectives that are most important to the decision. These are the ones most likely to affect your evaluation of the alternatives. You could then hold onto the objectives that didn't make the shortlist. When you compare the alternatives, if there is no clear winner based on the shortlist, you could then add in one or more of the lesser objectives and see if they impact the evaluation. 

Q: Some of the attributes given in the examples seem vague. Wouldn't it be helpful to make them more specific? For example, instead of having "Cost in dollars" as an attribute for "Minimize cost," why not decide what specific amount is the maximum and then use that as the attribute like "Costs less than $1,000,000."

A: The reason for leaving it less specific is to enable more informed thinking about trade-offs. If the attribute is "Costs less than $1,000,000," answers will then be either "Yes" or "No." But suppose that two alternatives are less than $1,000,000, but one's cost is $500,000 while the other is $900,000. You wouldn't want to lose that insight as you compare the alternatives against the other objectives. If there is a specific value that's relevant, there's always the option of adding an additional column in the spreadsheet indicating it as a target value (maximum, minimum, etc.).