Designing Decision Tables
Part 1: Basics

Summary:
Decision tables are an excellent means to represent the decision rules on which an operational business decision is based. But many decision tables are too technical. They are aimed at software developers, not business people. Do they have to be that way? No! Your approach should stay as close as possible to formats intuitive and natural for business people.
In this month's column, Ron Ross explains that decision tables are a key technique for business analysis. In this first part of a 3-part series he introduces you to the fundamentals of what you need to know to understand and design business-friendly decision tables effectively.

An example of a simple decision table is presented in Figure 1. This decision table addresses the question What coat should be worn?

Figure 1. Example of a Simple Decision Table

The decision table in Figure 1 can be used to answer four specific variations of the question What coat should be worn?, as follows.

What coat should be worn if it is cold and rainy?

What coat should be worn if it is cold and not rainy?

What coat should be worn if it is not cold and not rainy?

What coat should be worn if it is not cold but rainy?

The answers can be found in the appropriate intersection cells (for convenience, lightly colored), starting at the top row on the left, then reading clockwise.

Decision Rules and Outcomes

The answers to the four specific questions above represent four decision rules, which could be expressed as follows.

A lined raincoat should be worn if it is cold and rainy.

A wool overcoat should be worn if it is cold and not rainy.

A coat need not be worn if it is not cold and not rainy.

An unlined raincoat should be worn if it is not cold but rainy.

A decision rule is a business rulethat guides the making of an operational business decision,a business rule that provides a specific answer to a selective question.

A significant benefit of using decision tables is that there is no need to write out the decision rules as above (unless desired for clarification). Appropriate outcomes simply appear in the decision cells of the decision table.

An outcome is the result, conclusion, or answer given by a decision rule to a selective question being asked. Example:

Lined raincoat is the outcome given by the decision rule A lined raincoat should be worn if it is cold and rainy.

The outcome given by a decision rule is selected from among a set of potential outcomes, all the individual outcomes permitted for answering the overall question. Potential outcomes for the decision table in Figure 1 include at least:

lined raincoat

wool overcoat

no coat (none)

unlined raincoat

Other potential outcomes might exist besides these four. Identifying the complete set of potential outcomes is always an important concern in decision analysis.

What a Decision Table Is

A decision table is simply a structured means of visualizing decision rules in rows and columns.

TableSpeak optimizes for readability by non-IT professionals and business people.

The question the decision table answers is always emphasized.

Scope (applicability) is declared explicitly.

Unnecessary complications to decision-table structure (such as exceptions) are externalized.

Meaning is comprehensively expressed.

Business vocabulary is carefully used.

Decision tables based on TableSpeak are free of hidden assumptions and implicit interpretation semantics.

The Cases that a Decision Table Addresses

What we want from a decision table are the answers to a question. First, however, the decision table must be structured properly to provide and manage these answers in optimal fashion.

The most fundamental idea in structuring a decision table is that it addresses particular cases of interest.

A case is simply some particular situation — nothing more, nothing less. Cases might be called scenarios, but we prefer the term case to avoid any sense of events or actions — i.e., 'flow'. Think of a case as a snapshot of circumstances that at least momentarily don't flow.

The decision table in Figure 1 specifically addresses the following four cases:

It is cold and rainy.

It is cold but not rainy.

It is not cold and not rainy.

It is not cold but rainy.

These four cases are composite. Each is clearly based on two factors rather than just one:

Although considerations can always be worded as questions (as above) we do not insist on that. For example, the two considerations above could be called temperature and precipitation, respectively.

The key is to word or name each consideration in a clear, business-friendly fashion.

How many considerations should a decision table include?

The decision table in Figure 1 involves two considerations.

Many decision tables, of course, involve more than that. As more considerations are added, the complexity of representation, analysis, and management naturally escalates.

It is generally recommended that the number of considerations for a decision table not exceed 7.

What kinds of cases can considerations produce?

Considerations produce two fundamental kinds of cases, elemental and intersection, as discussed below.

Elemental Cases

An elemental case is a case produced directly from a single consideration. Examples:

The consideration Is it cold? produces the two elemental cases:

Yes, it's cold.

No, it's not cold.

The consideration Is it rainy? also produces two elemental cases:

Yes, it's rainy.

No, it's not rainy.

How should elemental cases be worded?

Elemental cases need not be specified in quite so wordy a fashion as above. For example, simply yes and no would probably suffice. TableSpeak, however, always focuses on avoiding any possibility of ambiguity or misinterpretation. Good judgment in this regard should be exercised.

Note that cases are never worded as questions.

How many elemental cases can a consideration produce?

The two considerations above are binary — they each produce two elemental cases. Many considerations produce more than two cases. Examples:

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:

Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.