During a recent Facilitating a Requirements Workshop class, my students and I had discussion regarding decision criteria. While the discussion came out of a class centered on business analysis, the answer resonates with almost any industry. Since my students asked me for a quick write up to reference, I thought it might help others and wanted to share. First, let’s take a quick step back to the question that started our discussion.
How do we decide which alternative is the best when trying to help a group make a decision?
We should always employ decision criteria in making any decision. Let’s explore this by using an example of trying to decide which car to buy. What is important to us that will help us determine which car will best fit our situation? Is it style, comfort, noise, gas mileage, speed, manual/automatic transmission, accessibility, price, payment terms available, reliability…?
You can think of this criteria as part of the user story around the decision being made. For example, this user story might apply to some: “I need the car to look cool so that I can impress people.” One that is much more realistic for me would be “I need the car to be reliable so that I don’t have to worry about breakdowns in traffic.” The criteria are going to help you determine that a successful decision has been made. In this example, success would be that we purchased the right car for our situation.
The decision criteria in a business setting are those variables or characteristics that are important to the organization making the decision. They should help evaluate the alternatives from which you are choosing. I use the word “variables” because you can disregard any characteristics that are constant among the alternatives. For example, if all of the cars I am evaluating get the same gas mileage, then disregard that characteristic as it will not help you choose between the alternatives.
The decision criteria should be measurable and should be within scope of the problem you are trying to solve. On criteria that seem immeasurable, you should at least be able to compare one to another. For example, the typical software characteristic “user friendly” is not measurable as stated. You could either list out what makes the application user friendly for your organization or you can try out the applications and have a rankings for the alternatives on relative “user friendliness” between them.
Typical Decision Criteria
- Ease of implementation
- Cost
- Ease of modification/scalability/flexibility
- Employee morale
- Risk levels
- Cost savings
- Increase in sales or market share
- Return on investment
- Similarity to existing organization products
- Increase in customer satisfaction
When in a group decision-making situation, it is often helpful to have the group brainstorm the decision criteria. This helps ensure buy in of the decision itself because the criteria is measurable and not just a “well I feel like we should buy this product because I like it.” You might also weigh the criteria. For example, cost savings might have a higher weight than ease of use.
Following a structured decision making process will not only enable faster decision-making, it also improves the probability that you will get a consensus on the decision. Consensus is determined to exist when the entire group agrees to support the decision, even if they do not totally agree with it. When getting a group to make a decision, an open discussion with logical presentation of the decision criteria will drive the group toward consensus.
Our Facilitating a Requirements Workshop Course gives you an opportunity to practice establishing and applying decision criteria in a group setting. I also recommend downloading a copy of our Decision Making Process Template. This tool helps you define decisions that may be made by your team and identify who “gets a seat at the table” when those decisions need to be made. It can help your team get off to a great start by defining the path of decisions and decision-making roles.
Thanks,
– Ali
Editor’s Note: This blog post was has been previously published by B2T on our previous website. Due to its popularity, Ali has updated its content to be more comprehensive and accurate for the state of today’s environment.
Ali Cox
LEAD EXPERT
Alison (Ali) Cox has experience since the mid-1980s in various areas, including business agility, business analysis, project methodology development and training, systems development (mainframe, client-server, and web), and telecommunication expense management. She began her career in the financial services area, and then moved into systems development for accounting systems.
Ali has lived through IT and operational initiatives from waterfall to implementing agile in her own small business, then helping other companies do the same through training and mentoring. She believes that having the small business mentality (everyone has to pitch in on everything) is the right kind of mindset for all organizations, no matter the size or industry.
Ali is the author of Business Analysis for Dummies, 2nd Edition.
