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

Guide 10

DEVELOPING USER RESPONSES
TO EPISODIC OCCURRENCES

For users of STEP/MES Episode descriptions

Reading time is about 25 minutes.

Table of Contents

INTRODUCTION

This Guide is for users of STEP-MES-based User Action Statements to help them develop user actions responsive to their needs for action .

It utilizes the User Action Needs Statements (UANS) developed in Guide 8 and other inputs to produce proposed user response actions. While analytical rather than investigation tasks, the Guide is provided to show how the STEP-MES arrays have utility beyond just providing an understand of what happened. This capability is a natural feature of STEP-MES investigations to help analysts

    develop response actions for each user needs statement

    predict the potential effectiveness of each option,

    turn "best" options into user actions, and

    determine results achieved after user's action is implemented.

OBJECTIVE

The objective of this Guide is to enable user's analysts to discover, define and select the best possible response actions to meet each user's response action needs, and to assure the efficacy of chosen actions.

APPLICABILITY

Applicability of the guidance provided through Guide 8 was essentially generic, applicable to most kinds of episodes. This Guide's contents can not be generic, because of the different user missions, functional expectations and kinds action options possible.

Originally designed for accidental or unintentional episode response action development, the STEP-MES array's utility for other users and uses evolved. Three kinds of episodes are investigated: unintentional and natural episodes and willful episodes. Part A is applicable to all. Part B is applicable to response actions for unintentional (accidental) and natural episodes, and Part C is applicable to response actions for willful episodes.

DATA REQUIRED

User action needs statements (UANS)provide the starting data input for this function.

Additional data sources are determined by user functions, and their data needs. The additional data for this task, such as understanding of their entity's internal functions, policies, procedures, system designs and operations, trade-off considerations and, sometimes, check lists to find options and predict effectiveness. Acquisition of such data is required to select the best options to recommend

PART A. USER RESPONSE ACTION DEVELOPMENT - GENERAL GUIDANCE

For each UNAS, ask what actions could be proposed to produce the results desired by the entity.

To anser that question, these are the typical tasks"

  • 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.

Strategies and tactics are available to help you with this tasks. Depending on the analyst's functional relationship to an entity, a simple strategy may be to consider past actions as precedents for satisfying a need, and propose that action, modifying it to accommodate specific details of the episode or system. For example, to settle claims, precedents might offer a model for action. Each user has such precedents. However they may not always be applicable. define the problem or need and then simply propose 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.

PART B. USER RESPONSE ACTIONS - UNINTENTIONAL EPISODES

For each UNAS, ask what changes could be introduced to produce desired outcomes for processes or activities in which the episode occurred. the the BB pair. Relevant strategies and tactics are available to help you with this tasks. Depending on the analyst's's functional relationship to an organization, the best strategy may be to define the problem or need and then simply propose 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 action produced the desired results.

1. Technical Strategies.

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

  • Apply energy management strategies (See Figure 8-3)

    Figure 10.1 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 (or avoide) the

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

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

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

    E  ffects - Can the Effects or the input-output relationship between the BBs be changed? or

    L  ocation - Can the Location of the BBs 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 BB pairs in this way demonstrates the creative value of STEP-MES-based matrix arrays with linked BBs.

2. Identify action 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.

3. Predict effects of each candidate option.

You want to prevent a new change from creating new problems. For each candidate change, consider the effects of the change that 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 BBs 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 11.3..

Figure 10.2 Control Rating Code Table

4. 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 occurrences, the surviving candidates need to be prioritized. This requires identification of the trade-offs influencing the 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.

5. Develop follow-on plan to determine that need has been satisfied successfully.

For the actions ranked most highly, a plan to monitor future activities to determine the degree of success for each is highly desirable. An easily implemented follow up plan for a complex action makes the action more attractive to the decision maker.

The STEP-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.

Figure 10.3. Example of STEP-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 proposed 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.

6. Prepare decision package for decision maker

The needs statements and data BBs in arrays influened 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 STEP-MES matrix array 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 proposed actions.

PART C. RESPONSE TO INTENTIONAL EPISODES

Intentional episode UANS may be based on a need for tort actions, for behavioral modification actions, security intervention actions, cyber countermeasures or other kinds of investigation data users' response actions. For these UANS some actions may be proscribed by laws or regulations, such as penalties, incarceration, civil judgments, etc. Others may be discretionary, such as decisions to prosecute perpetrators, or selection of research topics oer other analyses: for those the development of action options is the analyst's task.

In some cases, an intermediate action option might be to gather additional "evidence" (BBs) to corroborate a BB with a single source. Again, the users' response actions are determined by the mission and goals of their data needs.

USER QUALITY CONTROL

1. Real time quality control checks.

By following the above procedures, user 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 10.4. SAMPLE USER ACTION ANALYSIS WORKSHEET

(attach to each User Action Needs Statement page to avoid speculative proposals.)

TITLE: Name of investigation/ User Need Number No.
CONTENTS:
  1. Statement of the need to be addressed by a user action:
  2. State the proposed entity/position + action to meet the need, and strategy used:
  3. What alternative strategies and options did you consider?
  4. Who in what entity has resources to implement the user action? Can they get them?
  5. Will proposed user action work without testing it before it is implemented? If no, what are those tests?
  6. What groups will benefit from action/ ultimately pay for action? If different, is that OK?
  7. Are the priorities for proposed action clearly presented and persuasive?
  8. Will trade-offs be acceptable to all? Rationale?
  9. What will be the initial response of those affected by the action?:
  10. Describe how everyone will know your proposed action has achieved desired results?
  11. Are there interim results everyone should be looking for? If so, what are they?
  12. What followup monitoring or actions should occur when during the activity's life cycle?

Remember this is the documentation that has to persuade others to act (and probably spend money.)

2. Other steps.

  1. Should other comments about this user action be solicited from other knowledgeable people?
  2. Review the tabs on the BBs and links to ensure none have been overlooked.
  3. It is 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 effects of user action follow.

3. DO NOTS in ACTION proposals.

  1. DO NOT pick a definition of need from a past investigation for this episode; make each action dependent on this investigation.

  2. DO NOT rely on intuition: do use logical analytical reasoning.

  3. DO NOT propose something just because you think it would be nice to get it done.

  4. DO NOT confuse design and execution - more training vs. redesign training program.

  5. DO NOT aim action at low-level employees: they can't usually get much done! DO go to the power.

  6. DO NOT throw a "stink bomb" into somebody else's room and run; be willing to do it yourself if asked.

  7. DO NOT force a career decision on someone unless it is really important to get it done.

4. ESSENTIALS for action proposals.

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

  • Use MES-based Matrix arrays: proposed actions have to be based on BBs that actually occurred.

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

  • Prioritize the most significant BBs, links, or BB sets to address.

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

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

  • 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 "cause," blame, fault, guilt trips.

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

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


[ 1 ] For an extensive discussion of the actions to propose, its problems and solutions, see Benner, L. RANKING 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 11