© 1979-2003 by Ludwig Benner, Jr. .All rights reserved.


Guide 8

DEVELOPING RECOMMENDED ACTIONS
FROM MES MATRIXES

For Use During MES-Based Investigations

Table of Contents


Go to Guide: 0 1 2 3 4 5 6 7 8 9 10

INTRODUCTION

Multilinear Events Sequencing technology provides a unifying process to develop effective recommended actions from the description of an occurrence. This process uses the tested MES Matrix and the relationships described on the Matrix to

    discover and define needs demonstrated by the occurrence,

    select needs to address with recommended actions,

    identify options for actions to resolve each need,

    predict the potential effectiveness of each option,

    turn "best" options into recommended actions, and

    determine results achieved after it action is implemented.

Development of recommended actions requires an investigator to thoroughly understand the occurrence. The MES Matrix provides this understanding in a format the lends itself to the needs definition and recommended action development process.[1] The same EB pairs used to test the quality of the Matrix are used to discover candidate needs and develop recommended actions.

While they have some commonalty, these development procedures differ in major ways from the investigation procedures used to develop the description of the occurrence. Investigations to determine what happened are retrospective; the investigator must figure out what happened from "historical" data, after the fact.

Recommendations, on the other hand, are designed to influence future behavior and performance, and must therefore be predictive in nature. Other differences include data sources, data acquisition methods, need assessment methods, effectiveness assessment and prediction methods, quality control processes and future monitoring and verification tasks. Writing approaches, styles and contents also differ markedly. All are described in this Guide.

OBJECTIVE

The objective of this Guide is to present procedures that can be used to discover, define and select needs, find and select the best possible actions to meet each need, and control the quality of recommended actions.

APPLICABILITY

This recommended action development process can be used during any MES-based investigation, or to develop recommendations from a group of MES-based investigation Matrixes.

DATA REQUIRED

This recommended action development process requires MES Matrixes with linked Event Building Blocks to function efficiently. The process uses additional data about system design and operations, needs evaluation criteria, trade-off considerations, and check lists to find options and predict effectiveness. Acquisition of such data is required to select the best options to recommend.

DATA SOURCES

The data sources include the MES-based worksheet and at least the following additional sources:

  • Descriptions of the systems where new action will be introduced

  • People who will have to fund or implement actions being considered.

  • Monitoring systems that can provide information about past performance and operating parameters, as they relate to the actions proposed.

RECOMMENDED ACTION DEVELOPMENT PROCEDURES

The main tasks required to develop recommended actions after the occurrence is understood are to:

  • find, define and assess the candidate needs suggested by the description of the occurrence.

  • determine which needs should be addressed by some action.

  • pick technical strategy to address each need.

  • identify candidate control options.

  • predict effects of each candidate option.

  • identify and summarize implementation trade-offs.

  • develop a follow-on plan to verify that the need has been met successfully.

  • prepare a decision package for action by the proper manager.

The extent of the documentation should be determined as part of the investigation program plan. The risks and scope of the problem, cost of proposed actions, and sometimes other unique circumstances will dictate the extent and nature of the needs documentation and decision package. As a general rule, the contents of a needs statement, which must be persuasive to ensure action, would include the following elements:

DESCRIPTION OF WHAT HAPPENED
The interactions(Links) between [Event A], [Event B] and Event (n)...]
-State the event set that demonstrates the problem

DESCRIPTION OF ACTIVITIES INVOLVED
Demonstrate the problem is in the [description of the functional activity, such as operation, design, maintenance, staffing, policy, supervision, etc]
- define the organization function in which the problem occurred to indicate who "owns" the problem and will be responsible for remedying it.
- use "demonstrate," "indicate" or "suggest" a problem, depending on the strength of the logic supporting the definition of the system/subsystem X
- use additional attributes to define the specific system or subsystem

- DESCRIPTION the system or subsystem within which the problem exists or
- DESCRIPTION the systems whose interactions create the problem

DESCRIPTION OF WHAT THE PROBLEM IS
The problem is [define what problem is indicated by this event set.]
-state the problem in terms of the MOTEL strategies, or
- state the logic which explains the problem

EXPLANATION OF WHY IT NEEDS TO BE FIXED
The problem creates a risk with a [use RAC terms here for probability and severity ]of future loss which [merits or does not merit] action by [responsible manager]

- this is where the needs statement must convince the responsible manager that the problem is worth the manager's attention or manager can reasonably live with it in future.

DESCRIPTION OF WHAT NEEDS TO GET DONE
The relationship among these events must be changed to [control, reduce or eliminate] this risks they pose.

- state what needs to get done
- ensure that wording is compatible with tracking and followup actions


1. Find, define and assess needs

In this discussion, the reference to needs is intended encompass all the problems, hazards, risk-raisers and any other indicators of opportunities to introduce changes that might improve future performance.

First, develop candidate statements of the problem or need that could be addressed by the recommended actions. A need is some result that is to be achieved to better manage or change the course of interactions and outcomes in the future. A candidate statement of need is the documentation of what has to be achieved to "de-link" EBs. Stated another way, a need is a change that will produce a different process outcome, by modifying the relationship between EBs in a linked EB pair or set. Every EB pair should be examined to determine if a candidate need statement can be developed from the relationship.

Another way of looking at this task is the view it as a needs discovery and definition task. This procedure describes the candidate need definition task.

a. Select a starting EB pair. Start at the right end (outcome) of your worksheet and begin by selecting linked EB pairs to analyze, one at a time, from right to left on the Matrix.


NOTE:

    On a completed MES Matrix all linked pairs will have a cause-effect relationship. If the links are continuous from the first to the last EB, all the EBs had to occur for the occurrence to advance from its beginning to its conclusion or outcome(s).

b. Define needs. For each EB pair, ask two questions about the EBs and their link:

  1. Did the EB pair occur as it was expected to occur ? If the answer is "NO", the difference may indicate a need to change what occurred to match expectations. If what is supposed to happen is ambiguous, it may be necessary to change expectations to match what occurred. For example, that can be used to develop a needs statement. If the answer is "Yes" go to the next step

  2. Does something about the EB pair need to be changed to modify the relationship? If the answer is "YES" that points to a need: the system did not function as needed.

The general MES needs definition strategy is to try to identify possible changes to the elements of each EB set which would change the process interactions. To achieve the change, action to "de-link" the EBs is needed, so the relationships described will not occur in the future. Thus, the need is defined by the actions which would change future interactions.

De-linking can mean changing either EB in the pair or their linkage. EBs may need to be changed in any of several ways. For example, an EB's timing might need to be earlier, later, or not occur at all. Its duration might need to be longer, shorter or otherwise different. Its intensity might need to be stronger, weaker or different. Its location might need to be different, or its magnitude might need to be reduced if its influence on the next EB has to be changed. These are a few examples of how needs might be defined.

NOTE:

    The rule to remember is to define a need in terms of what is to get done, rather than in the form of a problem that simply states what is wrong. It is also a good practice to state the need in terms of "The investigation disclosed a need to ....." and keep out any extraneous discussion of all the past problems you have seen. Stick to the EBs and links.


  • Investigation Catalyst software provides for the recording of the following steps.

    c. Add "diamonds" If you determine that a need related to one of the EBs or the link does exist, mark the EB or link with a "diamond" containing a sequence number beginning with 1, and number your need statement with that number. This notation scheme provides a stable reference to the EB which indicated the defined needs. It also helps avoid duplication, and provides a quality control check point. It also helps investigators show reviewers that they considered a need even though it might have been dropped from later consideration


    Your numbered "needs diamond" attached to an EB or link is your record of your consideration of that EB and link during this procedure. If you see the same need at another EB, you can use a different number but define the need with the same words. Alternatively you can use the same number with a suffix such as 1a, 1b, so you can identify common needs by sorting on numbers, and yet know exactly where they were identified, but individual numbers are preferred. Where the recommended action development tasks are assigned to a single individual or group, it may be preferable to serially number every candidate need without restarting each diamond series in a new investigation with a 1. Where the recommended action development tasks are assigned to a single individual or group, it may be preferable to serially number every candidate need without restarting each diamond series in a new investigation with a "1." The choice depends on the manner in which the information is to be stored and retrieved, which varies from organization to organization.

    d. Work through EB pairs. After all needs statements have been completed for the first EB pair, continue through the MES Matrix to identify the needs indicated by each EB pair. The reason for looking at all the EB pairs is to ensure that candidate needs will not be overlooked - to minimize errors of omission. Remember to note each need with its own number in the diamond attached to the EB or link which demonstrates the need.

    NOTE:

      To manually record your work, it is a good idea to use a separate sheet of paper (or word processor page) for each needs statement. As the process continues, you will be adding information about each need and will quickly run out of room for those notes if you don't allow for it as you prepare your first notes.

      Investigation Catalyst enables you to do this quickly and efficiently.


    Figure 8-1 shows the general layout of the EBs, links and Diamonds on an MES Matrix. The configuration is the same in software Matrixes, but the appearance is different.

    Figure 8-1 Appearance of Matrix with Needs Diamonds

    e. Review markups. When you reach the last EB pair on the left of the Matrix, it is a good idea to review the marked-up worksheet with another qualified person to verify that all the needs have been identified. Alternatively, a second person could repeat the work you have done to verify the completeness of the needs identification task, and the results compared and harmonized. The main quality control procedure is to review the needs statements to ensure that they state each need in terms of the results needed, and not in terms of a problem.

    When all the candidate needs statements have been completed, and the Matrix contains all the numbered diamonds corresponding to your needs statements, you should be ready to proceed to the selection of needs that should be addressed by recommended actions.

    2. SELECT needs to address with recommendations.

    This procedure requires application of assessment criteria to rank the significance of the candidate needs statements. The criteria vary with the type of occurrence and purposes of an investigation. Thus they have to be developed by each organization performing investigations.

    a Prepare needs evaluation criteria. This step is dependent on many variables, such as its credibility, scope, resources affected, the organizational culture, its propensity for risk avoidance, the future availability of resources to address needs, the goals of its investigations, etc. One generally applicable tool for developing criteria is a rating matrix with 16-20 cells. Coordinates would be the considerations of interest, listed in some descending value or significance. In the safety field, for example, a widely used Risk Acceptance Code matrix illustrates the format of this kind of matrix. See Figure 8-2. The greatest risks are represented by 1 in the red boxes, and the lowest risks by a 5 in the white boxes.

    Figure 8-2 Risk Assessment Code Table

    Substituting other values for those shown would lead to a ranking method that could be applied to the candidate needs list.

    b. Assign rankings. Assign a significance ranking code to each candidate needs statement to order the needs on the list.

    c. Establish cut-off line. Reorder the list according to the rankings assigned. Draw a cutoff line below the entry on the list that represents the last need that will be further analyzed.

    Typically what happens during this procedure is that the number of needs subjected to further analysis is significantly reduced, but the quality (effectiveness, efficiency and timeliness) of the surviving candidates improves appreciably.

    3. Pick a technical strategy to address each need.

    For each diamond and the need it represents, ask what counter-changes could be introduced to produce routinely a desired relationship between the EB pair. Strategies and tactics are available to help you with this tasks. Depending on the investigator's functional relationship to an organization, the best strategy may be to define the problem or need and then simply recommend that the problem or need be remedied. The investigator's definition of success must be a part of that strategy: how will everyone know the problem is truly fixed.

    Other technical strategies range from energy control strategies to changes in task designs, or changing the timing of the EBs in your event pairings to the traditional idea of "breaking the chain of events." Examples of strategies include:

    • Apply energy management strategies (See Figure 8-3)
    • Figure 8-3 Example of Energy Management Strategies


    • Adapt better diagnostic procedures or improve human diagnostic and decision making knowledge and skills.

    • Use checklists derived from an ideal plan or a thought starter approach (See MORT Guide.)

    • Use the MOTEL approach - change the

      M  agnitude - Can the Magnitude of the EBs be changed?

      O  ccurrence - Can the Occurrence of either of the EBs or their linkage be changed?

      T  iming - Can the relative Timing or duration of the EBs be changed?

      E  ffects - Can the Effects or the causal relationship between the EBs be changed? or

      L  ocation - Can the Location of the EBs relative to each other be changed?

    Ask such questions about possible changes that might be considered. Often questions from someone unfamiliar with the operations are more creative than from someone who carries the burden existing assumptions and ways of doing business (experience.)

    Working with EB pairs in this way demonstrates the creative value of MES-based Matrixes with linked EBs.

    4. Identify candidate control options

    For each strategy, think of as many alternative ways as you can to implement the strategy. Note each candidate action on the needs statement. You often will identify more than one candidate action that could produce needed results. List all that occur to you so you don't stifle creativity. Candidates will be evaluated objectively as you go through the rest of the procedure.

    5. Predict effects of each candidate option

    You want to prevent a new change from creating new problems. For each candidate change considered, the effects of the change can be observed on the remaining parts of the MES-based worksheet. Those effects provide the basis for predicting and evaluating the benefits of a specific change in relationships between the EBs in the pair being examined.

    If the effects are unknown, that defines a data need for the investigator. It also indicates that the decision to select a particular kind of control for its effects on what will happen can be impossible if the effects are not predicted conscientiously.

    Evaluating candidates can be aided by criteria tables, developed to meet the needs and policies of an organization. Combining strategies to develop such tables is sometimes feasible. An example of such an evaluation tool for safety purposes is found in Figure 8-4.

    Figure 8-4 Control Rating Code Table

    6. Develop follow-on plan to determine need has been met successfully

    For the actions ranked most highly, a plan to monitor future activities to determine the degree of success for each is highly recommended. Such a follow up action plan should be considered in the trade-offs. An easily implemented follow up plan for a complex action makes the action more attractive to the decision maker.

    The MES Matrix provides guidance for selecting what can be observed, insights into where in the monitoring emphasis should be placed, and how "success" will be identified. If success in satisfying the need can not be identified, that is a signal of problems with the action being analyzed.

    7. Identify and summarize implementation trade-offs

    After the candidate changes have been screened to eliminate the ones which will have adverse or negligible effects on future events, the surviving candidates need to be prioritized. This requires identification of the trade-offs influencing the recommended action selection decision, and weightings assigned to each trade-off for each surviving option. Where the effects are minimal and the costs are minor, this can be done mentally and quickly; otherwise trade-offs should be documented.

    Trade-offs are identified most readily by tracing the interests of the parties involved in or affected by the action being evaluated. A simple trade-off worksheet and weighting scheme is typically used to rank the candidate actions for reporting and selection.

    Figure 8-5. Example of MES Trade-off Analysis Documentation

    Argument favoring
    Weight
    Rank
    Argument opposed
    Weight
    Rank

    Ranking criteria are best developed by users, since they are value-based. Each organization has its own value structure, and that can change over time. A good practice is to monitor the reasons given for acting on recommended actions, and building a criteria data base. Individuals who do the trade-off analyses should expect inconsistencies, and work toward a convergence of views over time.

    8. Prepare decision package for decision maker

    The needs statements selected, the action options that could be selected to address the need, the affected parties and their interests, and the trade-offs are then assembled into a written or documented decision package for the person who will have to sign off on the change. The decision package should also include either the MES worksheet or a narrative derived from the worksheet, plus as many illustrations as judged necessary for the specific decision maker.

    That package should be directed to the decision maker with the requisite level of authority to make the go/no go change decision. This seems obvious, but requires vigilance. Often analysts without organizational responsibility will load up a manager with a task that is not feasible, valid or implementable, without realizing the consequences. Good tradeoff analyses will reduce this kind of problem, and help you actually document the recommended actions.

    Recommendation Quality Control

    1. REAL TIME Quality Control Checks.

    By following the above procedures, recommended actions will usually be satisfactory. The following checklist will help to develop proposed actions, and serve as a check list for reviewing them. At the end of the checklist, additional points are suggested for consideration as quality control issues.

    Figure 8-6. SAMPLE ACTION RECOMMENDATION ANALYSIS WORKSHEET

    (attach to or make part of Needs Statement page where feasible.)

    Name of investigation/ Need Number/ Recommendation No.

    State the need to be corrected by the recommendation:
    State the exact wording of the proposed action, then the strategy applied:
    What alternative strategies and options did you consider?
    Who in what organizations has resources to implement corrections? Can they get them?
    Will proposed action work without testing it before you implement it? If so, what are those tests?
    What groups will benefit from action/pay for action? If different, is that OK?
    Are the priorities for implementation clearly presented and persuasive?
    Will trade-offs be acceptable to all? Rationale?
    What will be the initial response of the recipient(s):
    Describe how you and the recipient will know your recommended action has achieved desired results?
    Are there interim results you should both be looking for? If so, what are they?
    What followup monitoring or actions should be occur when during the system life cycle?

    2. Other considerations

    1. Should other comments about this recommendation from other knowledgeable people be considered?

    2. Review the tabs on the EBs and links to ensure none have been overlooked.
    3. It is also good practice to note the sources of trade-off ideas and information you relied on during this QC check.
    Some additional suggestions to avoid controversy or problems with monitoring recommendation effects follow.

    Some DO NOTs in preparing action proposals.

    • Pick a definition of need from past investigation for this occurrence; make each need dependent on this investigation.

    • Use intuition; use logical analytical reasoning.

    • Propose something just because you think it would be nice to get it done.

    • Confuse design and execution - more training vs. redesign training program.

    • Aim action at low-level employees: they can't usually get much done!
      Go to the power.

    • Throw a "bomb" into somebody else's room and run; be willing to do it yourself if asked.

    • Force a career decision on someone unless it is really important to get it done.


    Some ESSENTIALS for action proposals.

    • Use systematic and integrated analytic methods to identify results needed.

    • Use MES-based Matrixes: proposed actions have to be based on EBs that actually occurred.

    • Redefine needs to be addressed in terms of expectations versus actual occurrences.

    • Identify the most significant EB sets to attack.

    • Demonstrate the rationale for results that need to be achieved.

    • Propose new knowledge to meet need effectively, if it is needed.

    • Assign responsibility for results (Get everyone else off the bus.)

    • Always leave yourself an out: new information permits you to back away from the hardest position gracefully.

    • Follow up to see if it was done and if it worked; nobody does things automatically.

    • Show complexity to avoid single cause, blame, fault, guilt trips.

    • Understand what a standard procedure, standard or regulation is, and its limits before you recommend one.

    Upon completion of the countermeasure diamonds checks on the MES Matrix, proceed to the next phase of the MES process.

    [ 1 ] For an extensive discussion of the recommended action development process, its problems and solutions, see Benner, L. RANKING SAFETY RECOMMENDATION EFFECTIVENESS, Proceedings of 1992 conference, Dallas, TX, International Society of Air Safety Investigators, Sterling, VA

    Go to Guide: 0 1 2 3 4 5 6 7 8 9 10