Tag: Process

Workflow Design Principles, A Start

Posted on by tjustman

With any design principle, it’s a guideline, not a rule.  Design principles must be balanced and aligned to customer needs.  Building a house is a great example of balancing design principles against needs.  If you want a side entry garage, for example (so the neighbors can’t easily see your disastrous clutter) you likely need a corner lot.  But if your design principles tell you to avoid corner lots due to traffic and resale value, then you have a conflict of principles.  Same with these.

For the purpose of these principles, let’s loosely define workflow as steps taken in a presumably transactional process.  My lean towards transactional, information-based processes is strong in these, but I think they are generic enough to be applied to any workflow.  Indeed, I have applied some Lean Six Sigma, which are methodologies rooted in manufacturing.

Workflow Design Principles

  • Workflow should be progressed as far as possible by the same person before handing off to another associate, to automation, or to the customer (minimizes hand-offs and waiting time)
  • A task should minimize the number of systems the associate must use
  • A task should minimize switching back and forth between systems
  • A task should minimize the number of people required to touch it
  • A task should minimize manual computation or lookup steps (e.g. use of automatic calculations)
  • A task should minimize user judgement calls (e.g. use of decision tools)
  • Job roles/responsibilities and organizations should not be defined by the system, but rather by internal/external customer needs

How to apply these?  One approach would be to write them on a whiteboard as you work through designing a process and refer to them continually.  Also, once you have a completed process, review this list and then refer back to your process to see how well you adhered to them.  Again, with any design principles, you will need to consider your constraints and every one of them won’t be achieved fully.  By thinking about the ideal state we can start building a project backlog for future efforts.

I’d love your feedback, if anything, to add to the list!

Failure Modes and the Curious Case of Kevin McCallister

Posted on by tjustman

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

 

SIPOC Saves! Part One

Posted on by tjustman

“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?

Continue reading “SIPOC Saves! Part One” →

First Post, Welcome, and what’s a Process Sherpa?

Posted on by tjustman

Welcome to my little bit of the Internet! The purpose of this website is to connect my passion for business process improvement with those who share my passion or could benefit from it. I like the idea of sharing my experience with others to make positive change in the world!

                  Hillary and Norgay

What’s a “Process Sherpa?” On a practical level, I must admit it’s a domain name that hasn’t been taken! Ok, then what’s a Sherpa? Sherpas are the mountain people who live in the Himalayas and they are renown for being guides for mountaineers attempting the treacherous ascent of Mount Everest. These people are natural mountaineers, acclimatized to the oxygen-deprived atmosphere in the mountains. They lead the way, they know the route and the pitfalls, they carry oxygen bottles, and they make the journey possible. Sherpas seem to have been somewhat missed by history. If you’re like me (old!) you grew up being taught that the first person to climb Mount Everest was Sir Edmund Hillary, yet there was no mention of his Sherpa guide Tenzing Norgay! Now I don’t know how Mister Norgay took that snub but let’s assume the role of the Sherpa was to turn the mountaineer’s resources into success. The Sherpa takes the strategic direction from the intrepid mountaineer and turns it into accomplishment, without perhaps need for praise or fame, but satisfaction for a job well done. Part silent partner, part subject matter expert, and part project manager. In this context I seek to be your Sherpa of business process. You bring the strategic goal and I bring the know-how and the execution!

I ask for your strategic direction but what about mine? My objectives are to create awareness of tools, tips, pitfalls on the road to better processes. I want to share my stories – successful ones as well as failures – to engage your interest and open conversations. And I want to do it with my voice intact – I seek to avoid the dry, corporate, and clinical you get from my peers and really make this work FUN! Because life is too short, and I really want to work with fun people! I also NEED your input, your feedback, your stories, because I have so very much to learn!

So welcome aboard! please bring your comments, moaning, wailing, and complaints. Challenge me where applicable, and make me think deeper, because I aim to do the same for you!