A Decision Table Based Methodology for the Analysis of Complex Conditional Actions - Page 2

D. Robert Baker

Taking Action: Decision Table Methods for Describing Policy

Given that we have:

How do we get from the messy real world of policy to a nice, neat, unambiguous decision table in a spreadsheet ready for machine translation?

Step 1: Determine Policy Scope

A project without a predefined scope is subject to peril in the forms of:

It is often difficult to define terms for project scope that are unambiguous and easily determinable to meet the needs of all parties. The use of decision tables makes this a very straightforward task.

The scope of a policy project is determined by delineating all the policy that to be implemented. In decision table terms, policy implementation is expressed by actions. The project itself consists of determining and expressing the conditions under which these actions will be taken.

The scope of a decision table-based policy project is determined by enumerating all the actions that may possibly be taken. Such an enumeration is simple, unambiguous and clearly defines the boundaries of the project beyond argument.

Figure 5 a typical statement of scope for the policy expressed in Figure 1

Step 2: Determine Policy Authority

What are our policies, anyway? Where do we find them? Are they all written in point form in a big book somewhere? Is there one person in an office somewhere who knows them all and can explain them on demand? Probably not.

In most organizations, the sum total of policy is known and maintained by an intricate network of documentation and subject matter experts. It’s rare to find a single source.

Additionally, personnel come and go. Expertise is gained and lost. Documentation is constantly in a state of flux. New policy is added and old policy is phased out. There is usually a lag time in the maintenance of the corresponding documentation, often with documentation in different locations being updated at different times, if ever.

A definitive authority must be established for each area of policy of interest. This authority may be:

The more complex, indefinite, and ambiguous the policy, the more important it is to have properly constituted authority designated to interpret, and if necessary, more rigorously define it. Someone must have the final word.

Fuzzy logic in policy can be dealt with in decision tables as easily as in any other implementation. This is not to be confused with "fuzzy policy", which needs to be clarified by the appropriate authority before any implementation is possible.

Figure 6 a note on fuzzy logic

Step 3: Partition Policy

Policy should generally be partitioned in the interests of analytical efficiency. Different groups of analysts and subject matter experts can pursue work in different partitions in parallel. Bases for policy partitioning include:

Figure 7 a simple partitioning of the policy scope of Figure 5

Step 4: Elicit Conditions Associated with Actions and Policy Logic

With a firm scope (list of actions to be implemented) and the authorities to definitively interpret policy, the next step is to elicit from these authorities the conditions which affect the actions and the logic used to determine the actions given the conditions.

What form does this specification take? Asking subject matter experts at this point in the process to produce completed decision tables for the actions in their jurisdictions would be placing unnecessary expectations of sophistication upon them. In addition, it is desirable to collate interim results from all policy areas to gain efficiencies over the entire project.

At this stage, we need to gather two things for each of our partitions from our subject area authorities:

Subject matter experts should be asked "What questions would you need answered in order to decide on a course of action?". The source of the answers is unimportant. The answers to these questions may come from users, internal tables, instruments, or even distant databases. We are really looking for the data on which actions depend. For each question (datum) elicited, we need the following metadata:

The question format shows its value here. It makes it clear to the subject matter experts that actions are based on specific pieces of information and helps them to isolate these data.

Figure 8 annotated question list for Partition A and Partition B from Figure 7.

Note: subject matter experts have chosen default values to minimize the chances of serving free drinks should some information not be available!

Note: the default value for question B2 is dependent on the answer to question B1. This implies an order dependency of questions. This dependency must be kept track of for future reference.

Note: policy authorities must sign off on these analyses before proceeding.

A description of the logic used to decide on the actions based on the input data (answers given to the questions) The form of this logic is open. The best method of presentation is that which is at the same time:

The policy logic may be delivered in any form that meets these criteria, including those used in Figures 1, 2, 3, 4, or 9. The analyst must show his skill and creativity here in communicating with the subject matter experts to elicit, organize, and present this logic.

The analyst must ensure that:

Having gathered this information, the analyst must:

These authorities then must either sign off this representation of the policy area as correct and authorized or make such changes as necessary to complete this signoff.

Figure 9 Still another method of expressing policy logic

Page 1    Page 3   Back to the archive list