Christmas 1990 wasn’t so merry for the McCallister family, who learned an object lesson in how well they mitigate operational risk.  For those unfamiliar with this most disturbing and unfortunate case, young eight year old Kevin was left alone for a number of days in his posh Chicago home while his family visited Paris.  Only once she was over the Atlantic did his mother detect the failure mode.  As a result, Kevin became involved in some risky behaviors including petty theft, a scary neighbor, and battling two serial burglars.  As a parent I am forced to ask myself: what went wrong with the McCallister Family process controls?  

First, how did this defect in the familial deployment process occur?  Simply: Kevin’s presence was missed constantly throughout the deployment process.  Perhaps not unrelated, there was some animosity towards Kevin.  Key stakeholders referred to him as a “jerk” or one of “Les Incompetants.”  Kevin’s subsequent pushback to his operational lead sent him to remediation activity in the attic, which was preferable to reassignment with associate Fuller, who was noted as having issues with liquid retention.  Unfortunately, this action caused Kevin’s removal from the floor which resulted in his not being aware of movement, as well as out of view from other operational entities.  So the process seemed to rely on individuals to take their own required action, which alone isn’t enough to achieve the high level of process efficiency required to keep our children safe or parents out of jail.

The Parents McCallister, having at least five offspring, seemed aware of this potential failure mode (having deployed their children out of doors regularly we can assume) which is why they implemented a headcount control.  Unfortunately, this was not executed to standard since older child Heather accidentally counted a neighbor kid so the count was as expected.  Unfortunately this key control was delegated to a person who didn’t apply due care to count the correct children.  Perhaps she was incentivized on achieving the desired count at the expense of counting the right children?  Perhaps a Balanced Scorecard would have eliminated this principal-agent dilemma?  Hard to imagine a big sister would sabotage her youngest sibling, but they all did leave him home too.

The final control point that failed is one most students miss.  Recall back in Stone Age Pre Internet 1990 air travelers used physical tickets for transport.  So when the family showed up at the gate, there should have been one extra ticket right?  But the night before a gallon of milk spilled on the counter, and in the hasty cleanup Kevin’s ticket were discarded.  We don’t have information on who was responsible, but we can assume they were perhaps lactose intolerant or “Les Incompetents.”  The lesson here clearly is to not drink milk with pizza because that frankly is kind of gross.

What are the key takeaways beyond silly Christmas movie nostalgia?  In terms of controls, our choices are Detective (found the problem!), Preventative (stopped the problem from happening!), and Corrective (fixed a detected problem!) (more info here).  We like preventative controls the most for obvious reasons.  But controls not implemented correctly are not controls.  If control accuracy is a suspected problem, or if the item being measured is a significant risk, consider adding additional control or improve the reliability of the control system.  If using a multiple eyes approach, be sure to change the method of control so it’s not just a repeat performance.  In this example, either have big brother Buzz do an independent count (if he can count), or have mom or dad do it.  Better yet use different methodology by having one person count and the other do a roll call.  Further, I’d recommend the family sit down and complete a Failure Modes Effect Analysis (FMEA) with one of the fine people at Process Sherpa.  Taking a comprehensive look at the complete process and how things can go wrong will likely uncover many other failure modes not even considered.  This is especially important if the family continues to exercise this process without fixing all the possible problems.  (Sadly, McCallister deployment activity to Miami in 1992 also resulted in a similar situation.)

 

“Do you really have a handle on your process?”

SIPOC sounds like a failed science fiction character name.

 

Although “Star Trek 3: The Search for SIPOC” sounds like a rather uninspired sci-fi knockoff movie, the tool called SIPOC should be much more interesting if you’re trying to get a firm grasp of a process and need a productive way to start.  In this post I’ll explain what this tool is, when you should use it, and how you complete it.  In the second part I’ll discuss when such a simple little tool will save you!

So what is SIPOC?  It’s an acronym for: Suppliers, Inputs, Process, Outputs, and Customers.  It’s a tool that ensures you think about EVERY aspect of your process and beyond, specifically who’s involved, and what are they putting in or getting out of your process.  The actual process steps aren’t as important as what goes in and what comes out.  If you’re in the process you may not think too much of that, but if you’re an IT professional building in this space you worry about this quite a bit!  So the secret sauce of this tool is in the S, I, O, and C.  We don’t typically think of those elements when we think of a process.  And because of that, that’s probably where your problems live.

SIPOC Template. Five simple lists of things.

 

How do you know you have a handle on your process?  The best way is to take a look at SIPOC, explain it to your Subject Matter Experts (SMEs), process owner and perhaps some key partners (this won’t take long at all) and if the team can fill in the blanks quickly AND in near-total agreement, then you’ve got a solid understanding of your process. 

However, if substantial questions arise, then it’s worth the small amount of time (30-60 minutes) to go through the exercise with your process owners and stakeholders.  And trust me: this is NOT a waste of time, it’s actually a time saver!

Completing a SIPOC is pretty straightforward.  First, SIPOC is five independent lists of items.  Our purpose is to define the process boundaries – where does this beast start and where does it end – and to describe the process at a high level.  Fleshing out the “I” and “O” – the Inputs and Outputs does the first bit.  Then we need to identify who provides these – the Suppliers and Customers.  Suppliers are important because we will need to work with them in the future (e.g. ask for a change to an input).  And naturally the process exists solely to serve a customer (likely an internal customer – and just calling them a customer is often a paradigm shift!) so we need to identify them.  Naturally, customers will be stakeholders you must have at the process improvement table later.  (Promise me you’ll invite them?)

That leaves the middle column – Process.  (For my Canadian friends I’ll provide the alternate spelling: prohcess.)  For this, we actually don’t want a lot of detail.  Just describe it in about 5-8 high level steps.  How do you determine “high level?”  Imagine if you were compelled to explain to your future in-laws at Thanksgiving what you do at work, how would you do it so they could understand?  (They don’t have to care about it, just understand it!)  Simply describe the “what” of your process, and leave the “how” and the insider jargon in your in-law’s guest bathroom.  Your SIPOC is complete!

In part 2 (click here) we’ll talk about how you will be “saved” by this SIPOC. Please share your thoughts below – what did I forget? Are there some tips and tricks that I forgot about?