Introduction
This week’s MSLD632 blog
is about something that has become one of my favorite topics, the Cynefin
Framework for making decisions. Most of the decisions made within my span of
control at work are either simple or complicated and knowing which context (or framework)
is the best fit has been critical in good decision making. This blog will
provide 2 recent examples of how decision making outcomes could have had a
better outcome had the Cynefin Framework been utilized in the decision making
process as referenced in Snowden & Boone, (2007).
Interactive Fault
Isolation Tool Decision – Decision to Stop
My job for the past nine
years has been in-charge of writing fault isolation procedures for advanced
aircraft in development at the aircraft system level and is largely a deterministic
world, one where science and physics rule “The Simple and Complicated share the
common scientific assumption that lends much to conventional science and
wisdom.” (Obolensky, 2014, p. 54). Until recently these procedures have been
produced as in paper manuals. In spring of 2012 someone called me and informed
me the static procedures that my team had just completed for our latest and
greatest aircraft had been imported into an interactive fault isolation tool
and that our customers would soon have access to the procedures. My response “Oh
really, that’s great…would you mind if I took a look?” To make a long story
short, it only took a few moments to recognize that the import went very badly.
Every procedure I opened up was completely out of order when I began answer the
interactive questions. Something had gone horribly wrong. The explanation we received
from the 3rd party vendor who supplies the interactive fault
isolation tool was that the ‘reasoning engine’ was not behaving in a
predictable manner.
When this catastrophe
occurred (in the context of fault isolation data organization) the Cynefin Framework
was not known to me. Reflecting back on this event and using the Cynefin Framework
to find what action I should have taken, I find that I took the correct action.
Because the fault isolation procedures were in a state of chaos (unorganized
mess), the right action was to make a command decision and stop these
procedures from going to our customers until we could discover why the order of
the steps were not being displayed correctly. Snowden & Boone state this about
chaotic states “Take immediate action to reestablish order (command and
control)” (p. 73). The immediate action we took was to lock out the reasoning
engine by implementing predecessors for each step. In other words, we created
rules such that for Step 2 you had to do Step 1 first. In order to get to Step
3 you had to do Step 2 first, etc.
Interactive Fault
Isolation Tool Decision – Decision to Use XML and S1000D
In the above decision making
example, we used a mark-up language referred to as SGML (Standardized General
Mark-up Language). On the most recent project we decided to use XML (X-tensible
Mark-up Language) and a global technical writing standard called S1000D and
import into the same interactive fault isolation tool using a different import
tool.
The decision not to
author directly using the interactive fault isolation tool authoring mechanisms
was made without having enough or the right experts involved. S1000D is an
emerging specification, it’s been around for more than a decade but hasn’t been
on solid footing here in the USA in the aviation industry until just recently.
Because not enough analyzation was done and the right experts in the decision
making process were not involved, it has taken us the better part of 24 months
to experiment what style and format allowed within the S1000D specification would
work best with the import tool so that our steps would appear in the correct
order (same problem as in the first example). Once again we fell victim to not
understanding what it would take to make a good decision.
In this example there
are two critical points where the Cyenfin Framework could have helped. We could
have made a decision to not write using XML and the S1000D specification and
used the Spotlight tools to author the fault isolation procedures directly
without having to import them, and instead used the import tool to export the
procedures from the interactive state into S1000D. The reason behind taking
this approach this requires a lengthy explanation not really appropriate for this
forum, so you will just have to trust me when comparing the two processes as
fitting the data into the framework (importing the XML S1000D into the
interactive fault isolation tool) versus designing the framework around the data
(exporting the interactive fault isolation tool into the XML S1000D format). So
that sums up what critical point number one is about.
Critical point number
two is more about analyzing the problem better before jumping into picking a
solution. The problem was designing an authoring method that would import
properly so the steps of the procedure would show up in the right order (sound
familiar?) using XML and our S1000D framework. We thought we had a solution and
spent about 12 months developing the procedures using XML and S1000D before the
import tool was ready to use. When the import tool was ready, the results were
the same as before. What our 3rd party vendor calls the reasoning
engine was reordering the steps once again. Not wanting to install predecessors
again, I buckled down to find a solution. My intuition told me there had to be
one. We went thru several iterations of authoring intricacies before we finally
hit the right pattern.
My initial observation
about analyzing this problem better before picking a solution comes from
Snowden & Boone (2007) in from the Complicated context “Sense, analyze,
respond” and needing “Expert diagnosis”. At the time the decision was made, we
did not have as much direct contact with the experts as we did when we found a
solution and we were perhaps to confident in our original diagnosis. Snowden
& Boone (2007) caution against being overly confident in the complicated
domain and label this as a “Danger Signal” (p. 73).
Summary
If you are willing to
review the Cynefin Framework before making decisions you will reduce the amount
of poor or less than optimal decisions you make. I have shared with you two
personal examples of how the Cynefin Framework can help with decision making. There
is an excellent short video by Snowden The Cynefin Framework
that summarizes its. Hopefully reading my blog has had a positive effect on
your way of making decisions.
References:
Obolensky,
N. (2014). Complex adaptive leadership:
Embracing paradox and uncertainty. Burlington, VT: Gower Publishing
Company.
Snowden,
J., & Boone, E. (2007). A Leader's Framework for Decision Making. Harvard
Business Review, 85(11), 68-76.
