Flow Chart

The flow chart is a simple, but important, graphic organizer. Placing the states or steps of an event or process into the correct sequence allows you to reach conclusions and make predictions.

However, its simplicity means we don’t always work to be consistent and can benefit from a little effort to ensure users are aligned.

I am a huge fan of including flow charts in all process and procedure documents.

Steps for Building a flow chart

Capture

Capture the events or steps of the process. Resist the urge to arrange them sequentially and concentrate on capturing the events/steps only.

Cull

If there are more than eight steps in a flow chart we start creating cognitive overload. If a process or procedure has more than eight steps you need to:

  1. Ensure the steps are at the right level, sometimes we have substeps represented and we can cull that. Ensure they are all on the same level of process/procedure/task.
  2. Decide we need to break the procedure into multiple documents. This is a great way to decide what work instructions are necessary.
  3. Look for opportunity for process improvement.

Sequence the events and draw the flow chart

The focus now shifts to temporal relations. The correct sequential arrangements of steps or events helps to reach conclusions about past events and prepare for future events.

Example

I’m writing the procedure for my mornings, I capture the following:

  1. Eat breakfast
  2. Take shower
  3. Take dog out
  4. Get dressed
  5. Decide on tea
  6. Heat water
  7. Drink tea
  8. Read for 30 minutes
  9. Deal with morning email
  10. Snuggle with dog

Taking a look at the list I realize that not everything is on the same level of process/procedure/task and end up with a shorter list.

  1. Breakfast
  2. Take shower
  3. Take dog out
  4. Get dressed
  5. Read for 30 minutes
  6. Deal with morning email
  7. Snuggle with dog

Notice how I combined all the tea stuff into a breakfast category. When brainstorming my list I put a lot of weight on tea, because it is important to me (yes I have been using tea as a training example since 2005, I just love tea).

I can then put them in sequence:

Flow Chart for my morning

When I was making things sequential I realized that two of my activities (read and dog snuggle) were concurrent, so I combined them as one step.

Using the Outcome Identification Loop

The Outcome Identification Loop asks four questions around a given outcome which can be very valuable in understanding a proposed design, event, or risk.

The four questions are:

1Who else might this affect?Stakeholder Question
2What else might affect them?Stakeholder Impact Question
3What else might affect this?System/analysis Design Question
4What else might this affect?Consequence Question?
4 questions in the Outcome Identification Loop
Outcome Identification Loop

Through answering these questions, outcomes and relationships to further define a central question, and can be used to shape problem-solving, risk mitigation, and process improvement.

Questions 1 “Who else might this affect?’ and 2 “What else might affect them?’ are paired questions from stakeholder identification and analysis techniques.

Question 3 “What else might affect this?” relates to system analysis and design and can be fed by, and lead to, the chains of outcomes elicited using analysis methods, such as process modelling and root cause analysis.

Question 4 “What else might this affect?” considers uncertainty and risk.

These four questions can be iterative. Use them near the beginning to define the problem and then at the end to tie together the entire work.

Is-Is Not Matrix

The Is-Is Not matrix is a great tool for problem-solving, that I usually recommend to help frame the problem. It is based on the 5W2H methodology and then asks the question of what is different between the problem and what has been going right.

ISIS NOT
WhatWhat specific objects have the deviation? What is the specific deviation?What similar object(s) could reasonably have the deviation, but does not? What other deviations could reasonably be observed, but are not?
WhereWhere is the object when the deviation is observed (geographically)? Where is the deviation on the object?Where else could the object be when the deviations are observed but are not? Where else could the deviation be located on the object, but is not?
WhenWhen was the deviation observed first (in clock and calendar time)? When since that time has the deviation been observed? Any pattern? When, in the object’s history or life cycle, was the deviation observed first?When else could the deviation have been observed, but was not? When since that time could the deviation have been observed, but was not? When else, in the object’s history or life cycle, could the deviation have been observed first, but was not?
ExtentHow many objects have the deviation? What is the size of a single deviation? How many deviations are on each object? What is the trend? (…in the object?) (…in the number of occurrences of the deviation?) (…in the size of the deviation?)How many objects could have the deviation, but do not? What other size could the deviation be, but is not? How many deviations could there be on each object, but are not? What could be the trend, but is not? (…in the object?) (…in the number of occurrences of the deviation?) (…in the size of the deviation?)
WhoWho is involved (avoid blame, stick to roles, shifts, etc) To whom, by whom, near whom does this occurWho is not involved? Is there a trend of a specific role, shift, or another distinguishing factor?
Is-Is Not Matrix

Here is a template for use.

SIPOC for Data Governance

The SIPOC is a great tool for understanding data and fits nicely into a larger data process mapping initiative.

By understanding where the data comes from (Suppler), what it is used for (Customer) and what is done to the data on its trip from supplier to the customer (Process), you can:

  • Understand the requirements that the customer has for the data
  • Understand the rules governing how the data is provided
  • Determine the gap between what is required and what is provided
  • Track the root cause of data failures – both of type and of quality
  • Create requirements for modifying the processes that move the data

The SIPOC can be applied at many levels of detail. At a high level, for example, batch data is used to determine supply. At a detailed level, a rule for calculating a data element can result in an unexpected number because of a condition that was not anticipated.

SIPOC for manufacturing data utilizing the MES (high level)

Tree Analysis – Fault, Cause, Question and Success

The pictorial tree is a favorite for representing branching paths. Some common ones include Fault Tree Analysis (FTA); Cause Trees to analyze used retrospectively to analyze events that have already occurred; Question Trees to aid in problem-solving; and, even Success Trees to figure out why something went right.

Apple Tree illustration with long branching roots

Inductive or Deductive

Inductive Reasoning: Induction is reasoning from individual cases to a general conclusion. We start from a particular initiating condition and attempt to ascertain the effect of that fault or condition on a system.
Deductive Reasoning: Deduction is reasoning from the general to the specific. We start with the way the system has failed and we attempt to find out what modes of system behavior contribute to this failure.

The beauty of a pictorial representation is that depending on which way you go on the tree pictorially represents the form of reasoning that is used.

Inductive reasoning is the branches, and tools like a Cause Tree, are used to determine what system states (usually failed states) are possible. The inductive techniques provide answers to the generic question, “What happens if–?” The process consists of assuming a particular state of existence of a component or components and analyzing to determine the effect of that condition on the system.

Deductive reasoning is the roots, and tools like Fault Tree Analysis, take some specific system state, which is generally a failure state, and chains of more basic faults contributing to this
undesired events are built up in a systematic way to determine how a given failure can occur.

Success/Failure Space

We operate in a success/failure space. We are constantly identifying ways a thing can fail or the various ways of success.

Success/Failure Space

These are really just two sides of the coin in many ways, with identifiable points in success space coinciding with analogous points in failure space. “Maximum anticipated success” in success space coincides with “minimum anticipated failure” in failure space.

Like everything, how we frame the question helps us find answers. Certain questions require us to think in terms of failure space, others in success. There are advantages in both, but in risk management, the failure space is incredibly valuable.

Fault Tree Analysis

Fault Tree Analysis (FTA) is a tool for identifying and analyzing factors that contribute to an undesired event (called the “top event”). The top event is analyzed by first identifying its immediate and necessary causes. The logical relationship between these causes is represented by several gates such as AND and OR gates. Each cause is then analyzed step-wise in the same way until further analysis becomes unproductive. The result is a graphical representation of a Boolean equation in a tree diagram.

The Undesired Event

Fault tree analysis is a deductive failure analysis that focuses on one particular undesired event to determine the causes of this event. The undesired event constitutes the top event in a fault tree diagram and generally consists of a complete failure.

If the top event is too general, the analysis becomes unmanageable; if it is too specific, the analysis does not provide a sufficiently broad view.

Top events are usually a failure of a critical requirement or process step.

A fault tree is not a model of all possible failures or all possible causes for failure. A fault tree is tailored to its top event which corresponds to some particular failure mode, and the fault tree includes only those faults that contribute to this top event. These faults are not exhaustive – they cover only the most credible faults as assessed by the risk team.

The Symbology of a Fault Tree

Events

Base EventThe circle describes a basic initiating fault event that requires no further
development. The circle signifies that the appropriate limit of
resolution has been reached.
Undeveloped EventThe diamond describes a specific fault event that is not further developed, either because the event is of insufficient consequence or because information relevant to the event is unavailable.
Conditioning EventThe ellipse is used to record any conditions or restrictions that apply to any logic gate. It is used primarily with the INHIBIT and PRIORITY AND-gates.
External EventThe house is used to signify an event that is normally expected to occur: e.g., a phase change. The house symbol displays events that are not, of themselves, faults.

External does not mean external to the organization.
Intermediate EventAn intermediate event is a fault event that occurs because of one or more
antecedent causes acting through logic gates. All intermediate events are symbolized by rectangles.
Event Symbols used in a Fault Tree Analysis

Gates

There are two basic types of fault tree gates: the OR-gate and the AND-gate. All other gates are really special cases of these two basic types.

OR-gateThe OR-gate is used to show that the output event occurs only if one or more of the input events occur. There may be any number of input events to an OR-gate.
AND-gateThe AND-gate is used to show that the output fault occurs only if all the input faults occur. There may be any number of input faults to an AND-gate.
INHIBIT-gateThe INHIBIT-gate, represented by the hexagon, is a special case of the AND-gate. The output is caused by a single input, but some qualifying condition must be satisfied before the input can produce the output. The condition that must exist is the conditional input. A description of this conditional input is spelled out within an ellipse drawn to the right of the gate.
EXCLUSIVE OR-gate The EXCLUSIVE OR-gate is a special case of the OR-gate in which the output event occurs only if exactly one of the input events occur
PRIORITY AND-gateThe PRIORITY AND-gate is a special case of the AND-gate in which the output event occurs only if all input events occur in a specified ordered sequence. The sequence is usually shown inside an ellipse drawn to the right of the gate. In practice, the necessity of having a specific sequence is not usually encountered.
Gate Symbols used in a Fault Tree Analysis

Procedure

  1. Identify the system or process that will be examined, including boundaries that will limit the analysis. FTA often stems from a previous risk assessment, such as a FMEA or Structured What-If; or, it comes from a root cause analysis.
  2. Identify the members of the Risk Team. The Risk Team is comprised of the Process Owner, the Facilitator, and Subject Matter Experts (SMEs) with expertise in the process being reviewed.
  3. Identify the Top Event, the type of failure that will be analyzed as narrowly and specifically as possible.
  4. Identify the events that may be immediate cause sof the top event. Write these events at the level below te event they cause.
    1. For each event ask “Is this a basic failure? Or can it be analyzed for its immediate causes?”
      1. If the event is a basic failure, draw a circle around it.
      2. If it can be analyzed for its own causes draw a rectangle around it (NOTE: if appropriate, other event types are possible)
  5. Ask “How are these events related to the one they cause?” Use the gate symbols to show the relationships. The lower-level events are the input events. They one they cause, above the gate is the output event.
  6. For each event that is not basic, repeat steps 4 and 5. Continue until all branches of the tree end in a basic or undeveloped event.
  7. To determine the mathematical probability of failure, assign probabilities to each of the basic events. Use Boolean algebra to calculate the probability of each high-level event and the top event. Discussions of the math is a very different post.
  8. Analyze the tree to understand the relations between the causes and to find ways to prevent failures. Use the gate relationships to find the most efficient ways to reduce risk. Focus attention on the causes most likely to happen.
FTA example using lack of team (basic)

The Question Tree

A critical task in problem-solving is determining what kinds of analysis and corresponding data would best solve the problem. Rather than a shortage of techniques, there are too many to choose from, we can often reflexively use the same few, basic tools out of familiarity and habit. This can mislead when the situation is complex, non-routine, and/or unfamiliar.

This is where a Question Tree comes in handy to determine what analyses and data are suited for a particular problem-solving situation. This tool is also known as a logic tree or a decision tree. Question Trees are structures for seeing the elements of a problem clearly, and keeping track of different levels of the problem, which we can liken to trunks, branches, twigs, and leaves. You can arrange them from left to right, right to left, or top to bottom— whatever makes the elements easier for you to visualize. Think of a Question Tree as a mental model of your problem. Better trees have a clearer and more complete logic of relationships linking the parts to each other, are more comprehensive and have no overlap.

The Question Tree is very powerful when working through broad and complex problems that no single analysis or framework can solve. By developing a set of questions that are connected to one another in the form of a tree we can determine what data analysis is needed, which can help us break out of the habit of using the same analysis tool even when it is a bad one for the job.

The core question is the starting point. It is made easier to solve by decomposing it into a few, more specific sub-questions. The logic of decomposition is such that the answers to these sub-questions should together fully answer the question they emerge from. The first level of sub-questions may still be too broad to solve with specific analyses and data, so each is decomposed further.

The process of decomposition continues until a sub-question is reached that can be answered using a particular technique or framework, and the data needed is specific enough to be identified. A Question Tree is thus constructed, and the final set of questions indicates the analyses and data needed. As much as possible, the questions on the tree are also framed such that they have “yes” or “no” as potential answers.

They, too, are hypotheses to be settled with data, analysis, and evidence. They can also be used to test assumptions and beliefs, evaluate expectations, explore puzzles and oddities, and generate solution options.

In decomposing a question, ask whether the sub-questions are mutually exclusive and collectively exhaustive. This can help generate the sub-question not asked, and thus, reduce errors of omission. Building a Question Tree is an iterative and nonlinear process. If later information so dictates, previously done work on the tree should be adjusted.

Judgment plays a role in building a Question Tree, so it is unlikely that two people working independently on a complex starting question will create identical trees, but these are bound to overlap. Expertise matters and the strength of teams should be leveraged.

Success and Cause Trees

These are variations of the fault tree analysis: a Success Tree where the top event is desired and a Cause Tree used to investigate a past event as part of root cause analysis.