When Continuous Improvement is Confused with Continuous Improvement Programs

Posted on September 25, 2024September 25, 2024 by tjustman

MAIN POINTS

Creating the Culture of Continuous Improvement
Defining Your Objectives
Why Bother with Continuous Improvement?

When Continuous Improvement is Confused with Continuous Improvement Programs

BOTTOM LINE UP FRONT

Executives may think that “implementing Lean Six Sigma” or other business efficiency initiative will drive business results (cost reduction, revenue increase, risk reduction), when in reality what they should be seeking to do is to create a culture and practice of Continuous Improvement. The reason for the confusion may lie in the fact that doing this is very, very, hard. In fact, success or failure here will make the difference between success and failure of the firm.

BACKGROUND

I recently saw a LinkedIn post from presumably an executive, who sent all his people to get Lean Six Sigma certified. He didn’t see the benefits from “all the tools” and then said he wished he had them learn “Kana” instead, with a photo of some iceberg with terms under the water line that represented what he really wanted from his efforts. Frankly I can’t remember because they were some pretty core principles behind Lean Six Sigma in the first place (customer focus was one of them). So, I’m pretty sure this post is one of those troll efforts to elicit engagement, but since I didn’t take the bait, I can’t refer to it directly. But what I can do is answer the question: why do you even want Lean Six Sigma, and what is it that you really should want. Short answer is that every organization needs to have a culture and practice of Continuous Improvement.

THE CONTENT: DEFINE THE OBJECTIVE

A culture of Continuous Improvement means that all employees in their heart believe that they are owners of their work and that they are empowered to change it.

A practice of Continuous Improvement means that there are routines, resources, and practices that support the culture and facilitate employees’ Continuous Improvement work.

WHY BOTHER WITH CONTINUOUS IMPROVEMENT?

Why do you want a culture AND practice of Continuous Improvement? Because that is the goal that you’re after that will drive business results – the What! Lean Six Sigma, Toyota Production System, and likely many others are the tools – the How. But executives probably have an easier time throwing dollars at a How than a What. If you ever get into podcasting, one of the first things you’re told is to not go out and spend $2000 on equipment, because that isn’t what you need to do when starting out. Those are tools, and tools in the hands of a poor craftsman represents poor work done better. You need to find what value you have to offer, and then craft your offering. For executives, no doubt there are easier Harvey Ball charts that can be created to capture the progress towards the How of a Lean Six Sigma deployment, but it’s harder to show a Harvey Ball that tells us whether your employees have taken Continuous Improvement truly to heart – beyond the inevitable lip service, head nods, and platitudes.

Just like every employee has some baseline skills in communication and work ethic, every employee needs to have some baseline skills in Continuous Improvement (CI). Unlike communication and work ethic, not having CI skills won’t hurt you for most of the lifespan of the firm, which is why they are likely not there! If you think about the end-to-end journey of a skydiving trip, you don’t ever need to know how to operate your parachute until the very end.

If your organization is talking about CI, it may mean that you’ve enjoyed a meteoric rise to greatness, your products sold themselves, and you’re fat with cash and lazy processes. But something’s changed that refocuses attention on your business results. Maybe you sold your company to new owners who see untapped potential. Perhaps market share is slipping, products are underwhelming, revenues are down, and costs are up. You need a renewal. Or else. CI is the renewal you need to rebuild your organization the way it should have been built during that time when you were in growth mode.

CONCLUSION

Don’t get confused on what you’re trying to do. If you’re thinking about some package of business tools, as the solution, first think about what your problem is. Then think about what you need to do to get there. THEN consider what tools might could SUPPORT your real objectives. Don’t try to change your oil by leaving the oil filter wrench on the passenger seat. Go learn how to change the oil, and make everyone believe in their heart the oil must be changed.

CI Culture: The Traits of the Continuous Improvement Leader

Posted on September 25, 2024 by tjustman

CI Culture: The Traits of the Continuous Improvement Leader

Bottom Line Up Front

Building an organization that has a strong Continuous Improvement (CI) gene in its DNA requires leaders who exhibit the qualities that make this possible. These “Traits” are the first of three parts of how I define the CI Culture (followed by “Mindset” and “Derailing Behaviors”). I share with you my list of qualities in the hopes of stimulating thought, reflection, and healthy debate! In the article I make suggestions on how this list can be useful to you.

My List:

1. Change agent – you love to make improvements

2. Truth seeker – no sacred cows, no hiding what’s really happening

3. Patient – change is hard and it takes time to win hearts and minds

4. Business savvy – got to understand cost, revenue, and risk

5. Data savvy – you can’t improve what you don’t measure

6. Influence – winning hearts and minds with love and kindness

7. Prioritizer – we can’t work on everything and our time is irreplaceable

8. Organizer – respect each other’s time with competent planning

9. Culture builder – live the values and actively build them in others

10. Grit – this is tough business – you will need to dig deep

11. Happy warrior – but what we do is really fun, especially when we win

12. Willing to get dirty/go to Gemba* – don’t stay in desk defilade – get out there!

13. Good listener – remember you were given 2 ears and only 1 mouth for a reason

14. Can talk from top to bottom – everyone is important and needs to be won over

Background:

As a Continuous Improvement (CI) leader, I’ve experienced being in an organization trying to drive change, and the people around you simply don’t get what you’re doing at the core level of their being. Sometimes, organizations try to deploy CI in pockets, which spells failure if the culture isn’t right or if there isn’t critical mass of CI-capable professionals present to get traction. Organizations that want to build their CI capabilities may hire consultants to conduct Lean Six Sigma or other training without addressing the culture first – truly putting the cart before the horse, and making success unlikely.

The Content

If you seek to build Continuous Improvement (CI) as a skill set in your organization, then you need leaders who espouse the values of CI, which means you need to know what they are so you can select for them!

Firstly, the executives at the top of the house need to embrace these values. That may be problematic if they got to their positions following different values. In some cases, they may not have reached a maturity level in their career to understand these values – think family-owned company that is grown up to that first big inflection point and gotten acquired by a PE firm. They may have ridden a wave of market expansion that was driven by technology rather than managerial prowess, and now that sales have plateaued, the business is suddenly challenging.

Secondly, if your firm is seeking to deploy CI capabilities, it probably isn’t because everything is going swimmingly. Your competition may be out-maneuvering you. You may be losing market share or pricing power. You are realizing you must change or die. To change you need people who think differently than the ones who have put the firm in a position of weakness. Use these traits to select for winners.

Finally, you have great people who need to be won over or evicted. Performance evaluations – both formal and informal – need to be centered around these values. On every leadership call, leaders should be calling out associates who exhibited one or more of these values. Formal reviews should be conducted by assessing everyone’s performance in these terms. The C-Suite needs to talk these values over and over and over and over and over and over. Period. And then the line leaders will do so as well, and so on. These are the behaviors we want in our people, we will reward those who demonstrate them, and those who don’t exhibit them are not going to stay, because we can’t afford to keep them.

Conclusion

Organizations that demonstrate the qualities of Continuous Improvement are rare, but good ones do, and they win in the marketplace because they are adaptable, data-driven, customer-focused, empowered meritocracies. They are great places to work! Building this culture starts with understanding what you want. Once you set that destination, then you can hire consultants and buy training so long as those expenditures are driving the CI culture. If they aren’t, then get rid of them and try again.

*Gemba is a Japanese term that describes where the work really happens (literally “actual place”). Going to Gemba can be scary, inconvenient, or uncomfortable. My favorite Gembas: working 3rd shift picking and shipping medical supplies, walking under an incredibly hot and massive rotating limestone kiln, and sitting with fulfillment agents decisioning applications.

Why Your Processes Need to be Mapped

Posted on September 25, 2024 by tjustman

Why Your Processes Need to be Mapped

Process Mapping is an absolutely essential tool that is required to manage your business.

You may not have done it because of the cost. After all, why should you invest the time and energy to drag key subject matter experts and operational leaders into a room for what could be hours of work to create a document that tells us what we already know?

If your processes aren’t mapped, then you don’t know the process. In this situation, there are three versions of a process: what the process owners think it is, what the associates doing the process think it is, and what is actually happening on the floor. The process mapping exercise is key to get everyone on the same page. Once you get the first “oh…” in the room, then folks will be bought in.
A good process map is your primary tool to further continuous improvement activities. As you map your process, improvement opportunities will rain down on upon you. Don’t get sidetracked by them – stop mapping long enough to capture the thrust of the opportunity, write it down, write down who raised it, and keep moving. You will refine these later, and you’ll be glad you captured who brought it up in case you need more information!
The process map makes the KPI discussion much easier. If your process isn’t mapped I would suspect your KPI game needs some help. What do customers care about? What are the process outputs? How do we measure quality? Where are the sensors in the process that tell us we are having a good day or not so good day? Where are they now, and where should they be?

As W. Edwards Deming once said, “If you can’t describe what you are doing as a process, you don’t know what you’re doing.” If you’re in this situation, there’s no time like the present to get out of it. And if you need help, feel free to reach out to me!

Three Components of Process Risk: What’s in your Risk Wallet?

Posted on March 10, 2018 by tjustman

I suspect one of the benefits of working in banking is that the organization gets risk. Because banks live or die based on how well they manage lending risk. (See: subprime mortgage crisis, savings and loan crisis…) There are many forms of business risk but we’ll focus on operational risk, or what I’ll rename Process Risk (so I can write a book about it someday). It can be thought of in three ways:

It is continuous
It is objective
It is managed

Process Risk is Continuous. Risk isn’t really thought of in a binary fashion despite the outcome being binary (i.e. the risk was realized or not realized). Rather, Process Risk is on a spectrum because the probability of an event is on a continuum. The chance of an event occurring exists between 0.0 and 1.0. (For example, a coin flip resulting in “heads” has a probability of 0.5, or 50%. Until recently the probability of the Philadelphia Eagles ever winning a Super Bowl was widely considered to be 0.0 or 0%. Most of us supported this doctrine, until they went up against the Patriots.)

Not only does outcome live on this continuum, but the detectability of this outcome also exists between 0.0 and 1.0. Detectability is the probability of the process owner even realizing the outcome even happened. Best example of this? You are not enjoying your meal at a restaurant, yet you LIE like a dog to the server who dutifully asks “how is your Beef Stroganoff?” You know you do. Admit it. And I don’t even know you.

Note that the severity of the outcome is also continuous. As proof I’ll leave it to your imagination just how bad that Beef Stroganoff was (“was that beef?”). We incorporate these three continua into a wonderful tool called a Failure Mode and Effect Analysis, but that, dear readers, is another story.

Process Risk is Objective. Fear is not. Risk is analysis of fear. Analysis requires objectivity. Bring your fears into the light and they become assessed risks. When working on replacing the process that governed the home page at a Large Bank You’ve Heard Of (LBYHO) from a IT run/hand code approach to a business run/content managed approach, we discovered the fear that making this page easier to change would make it possible for a bad actor to vandalize the page. (Let your imagination run wild here. I’ll wait.) Given at the time LBYHO’s page was getting about half a billion page views per month, one could understand the concern and exposure. But this was simply a fear. Once we analyzed it in the terms above and considered the in-place controls, we logged it a process risk, and it ended up ranking very low, somewhere between Antarctic forest fire and losing a gerbil farm to a molasses plant explosion.

See the scary meteor? Boy is that scary.

Process Risks are managed. Just as in life, in our process we should not expect to eliminate risk but to minimize it. Meteors Happen. Elimination may become far too costly for the benefit, and this is where risk appetite comes in. I suspect to bankers that this attitude is more easy to accept in that banks don’t make money unless they lend, thus taking on risk. Banks take on risk every time they even open an account for a business or individual customer given account takeover and anti-terror concerns, thus accepting reputational and regulatory risk. Insurance companies actually make money explicitly managing risk, hopefully taking in enough premium money to cover losses, with a little profit for the shareholders and some Herman Miller chairs. In the military and aviation realms, risk management culture spans from top to bottom, and everyone learns how to assess it with tools such as acronyms and laminated risk management cards.

Managing a process inherently means managing Process Risk. Hopefully this short article has spurred some new thinking about how you approach that risk. Once you’re comfortable with these basic principles, I’d recommend learning more about the Failure Mode and Effects Analysis. This is psychotherapy for your process: it’s time-consuming and you often don’t see the point while you’re doing it. Although your parents don’t come up quite as often in the conversation, you often wish you were lying down. But in the end, you’re so much better for it. Gather the team for a couple of multi-hour sessions, cater in some Beef Stroganoff, and get to work.

The power of good design – Dieter Rams

Posted on January 8, 2018 by tjustman

This is great list of product design principles.

Reviewing the list I think every one of them is clearly applicable to process design. Even a process should have a nice aesthetic although that may come with achieving the other nine. I think this is a nice add-on to a design project charter and to have posted on a wall for easy reference.

I think it may be worth to expand on this list in the future and how each item applies to process design…

Workflow Design Principles, A Start

Posted on January 4, 2018 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!

SIPOC Saves! Part Two

Posted on January 4, 2018 by tjustman

So how does the SIPOC save me? This is an awfully bold claim, Cotton. After all, it’s a simple acronym and it’s pretty intuitive. It’s “I can’t believe consultants are highly paid to do this with us” simple. Well I’m a recent convert myself. As a baby six-sigma practitioner, my teammates raved about the SIPOC (like you probably did when you tried Thai food for the first time) but I just didn’t see it. Isn’t it just spicier Chinese? And then I was engaged on an uber-complicated 9-figure multi-year project that sought to redesign and move ancient processes that predated Lincoln (the president and the car

) into modern workflow and integration technology. The team put “product manager” and “business analyst” hats on the army of SMEs to sort out the mysterious processes and write user stories, but alas they knew the processes TOO well, and we desperately needed to pull them out of the weeds to be productive. And the weeds were ugly from years of adding layers of complexity to meet customer needs. So in this environment process design meetings continued but progress wasn’t being made.

I was asked to join one to see if I could help, and what was amazing was the realization that conversations were happening about the process with people who all had a different definition of the process. Because of a few factors no one was stopping the train to call out and resolve these differences. So I did. I put up a SIPOC template on the whiteboard, asked for 30 minutes to drive it out, and the exercise exposed broad disagreement on what process we were supposed to working on! Fortunately the SIPOC got them back on track and we made it a required deliverable early on for all other project teams.

I have yet to work on a project where time was cheap. The SIPOC will save you soft dollars for your employees AND hard project dollars for your contractors. Next time you are defining process for a project give it a try!

Please comment below with your questions, experiences, and feedback! We’d love to hear from you!

Failure Modes and the Curious Case of Kevin McCallister

Posted on December 27, 2017 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.)

A Penny Saved is a Penny

Posted on December 22, 2017December 22, 2017 by tjustman

As I’m researching Quicken Loans for potential business opportunities I came across a list of “Isms” and one resonated with me a bit. “A Penny Saved is a Penny.” This seems counter-intuitive since we’ve all heard “a penny saved is a penny earned” but I think in the context of rapid growth and innovation this revised version makes a lot more sense (cents?). And certainly in the context of Continuous Improvement I seem to have spent a great deal of time not on great ideas, but rather making sure all those great ideas are moving us forward, not keeping us motionless, or worse yet, moving backwards or at cross-purposes.

My favorite “aha” came from a deposits fulfillment process where we were considering how to speed up decisions for customers. Our process subject matter experts came up with an idea to speed up processing by a few minutes, and we put that on the “board” for consideration. Seems like a great little project, it will reduce handle time and fulfillment time while making a task less tedious, so a seemingly win-win-win for shareholders, customers, and associates!

But we also began to look at the process more end-to-end, and using that new lens we realized this project was just a penny. Because there’s little point in speeding up fulfillment for the customer by a few minutes, but when you look past the fulfillment processing step you found that fulfilled packages sit in an outgoing mail cart for an entire day! So we would save a few minutes so that a completed package could sit in an outgoing mail bin for an extra two minutes? That’s not even a penny!

How did we go wrong? Our fundamental assumption that once a package was processed, the customer “felt” that the task was completed. But in reality, the customer didn’t know their request was fulfilled until they received their package in Snail Mail. Our measure of completed cycle time was driven from internal system metrics, but your customer uses a different yardstick. You’ll do well to align your yardstick to the one the customer uses, because that’s the one he/she uses when reviewing your product or considering competitors!

SIPOC Saves! Part One

Posted on December 6, 2017February 21, 2018 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” →