Tag: Problem Solving

Neil deGrasse Tyson Doesn’t Like The Idea Of Superheroes… And Neither Should Your Organization

The other day I listened to a great discussion on a podcast from The Forward, with host Lance Armstrong.  The guest was Neil deGrasse Tyson, popular astrophysicist, (6.74M Twitter followers for an astrophysicist? wow!) Director of the Hayden Planetarium in New York, and host of The Cosmos. (Lance refers to him as a “rock-star” astrophysicist)  Neil commented on a variety of topics, from cosmic perspective, to the future of NASA, to science in schools, to what drives innovation, to the influence of his parents, and on how there are a higher number of microbes in one linear centimeter of your colon than the number of total human beings ever born.

I found his take on these and other topics to be humorous, logical, warm and inviting, and grounded in a long-term vision vs. knee-jerk short term reactions.  Science in schools?  He didn’t want to prohibit a state like Texas from teaching creationism if they chose to do so, he just wanted to make sure that state’s choice didn’t automatically proliferate throughout the rest of the country without it being their choice as well, and to make those responsible aware of the potential long-term economic impact that choice may have.

One discussion caught my ear from a Lean standpoint.  At 40:00 in, Neil has been discussing his father and family upbringing, how his parents nurtured their children’s interests, and then Lance asks “was he your hero?”  Neil responds “I tried not to have heroes, because a hero – what is a hero… I like what Carl Sagan said about superheroes one day – he didn’t like the idea of superheroes, because they make the rest of us complacent – oh, there are problems in the world, the superhero will take care of it, i’ll sit back and watch that happen…. a superhero allows people to not have to take responsibility over their fate.

This next statement may be an over-generalization, but I’ve seen it discussed enough I feel it is broadly applicable:  Employees in larger organizations have historically been rewarded for being the superhero.  They come through in the clutch, they bring knowledge and experience no one else has, they get results.  Oh, we have a difficult quality problem?  Bring in the specialist.  She’ll help us solve it.  Oh, that machine isn’t working right?  Call in Jim, he’s the only one trained on how to get it back up and running, he’ll know what to do and help us save our production numbers this shift.  These organizational superheros get the praise and recognition, get the most high-exposure assignments, and tend to get the highest performance ratings and promotions.  So… what’s wrong with this model?  Why wouldn’t I want to assign the most important projects to the people that tend to get the best results?  Why wouldn’t I want to reward my high performers so they want to stick around my organization, continuing to drive great results?

There isn’t technically anything wrong with that concept.  Many organizations have done (and still do) just fine with that model.  Wrong isn’t the right word to use.  A more complete description would be that it is your current state, but that the organization could evolve to be more efficient overall, could realize a higher potential utilizing all of its resources to their maximum capabilities, and be built to deliver and sustain results over time.  In an organization where superheros can thrive, it is as Carl Sagan (possibly) said – the rest of us can become complacent.  We may see a problem, and just say oh, Robert will be able to solve that for us, let’s just wait until he has some time free up.  We wait.  And while we wait, the waste caused by that problem continues.  Perhaps it grows. Perhaps it festers.  The benefit you would gain from improving the problem has been delayed.  And perhaps specialists like Robert get tired of operating in a crisis or high-pressure mode all the time and leave for another company environment.  What do you do then?

What’s the alternative?  An organization where everyone solves problems.  A community of scientists, a community of problem solvers, an organization where everyone drives improvement, from the shop floor to the executive office.  Instead of waiting for Robert, anyone can take on the problem, or the team can work on it together. No need to call in a specialist – let’s improve the situation now.  What does it take to build this type of an organization?

  • Balancing rewards equally between building capability in team members and achieving results
  • Rewarding solving problems to root cause vs. quick temporary countermeasures that make you feel good in the short term
  • Setting the expectation that everyone will learn to solve problems – and following it up with leadership modeling those behaviors
  • Asking questions rather than providing solutions or instructions, which empowers the team to think rather than simply to execute

So Neil’s comment about superheroes should really ring true with those who are in the midst of lean transformation.  And by all accounts, Neil is a pretty smart guy.  It isn’t about creating Lean Superheroes.  It is about studying your current organizational superheroes – what skills and knowledge do they have that enables them to consistently deliver results?  What about those capabilities can we extract from them and move from tacit knowledge to explicit knowledge that anyone can use?  How can I build those capabilities into the rest of the organization?  And most importantly, how can I enable my team to evolve into a community of scientists?  What obstacles are holding us back?

Take the time and reflect – do you have an organization that looks to its superheroes to solve problems?  If you do… is it possible this part of your culture is a reason your transformation is being held back?


An Ah-Ha Moment With A Simple PDSA Flowchart

Recently I saw Karen Martin post a PDSA flowchart on Twitter.  The graphic does a wonderful job of outlining the steps of problem solving and PDSA thinking, highlights the importance of defining your problem and how much time you might need to spend before moving forward in the process, and covers the question of “what does adjust really mean?”.  There’s a good chance printing this out and handing it to my leadership team in our next capability building session will generate some rich refresher discussion.

Karen Martin PDSA Flowchart


But there was one line on there that really sparked something in me as I read through it.  Line 3 says “Set a Target Condition”.  Seems simple, seems in line with most problem solving training… so why was I so interested?  What sent my brain off racing to analyze this line?  This line really resonated with me because many recent kaizen events I’ve been involved in struggle and bog down at the point of discussion about the target, especially if they are trying to go somewhere they’ve never been before vs. getting back to a level they’ve obtained sometime in the past.

Yes, the problem is the difference between target and actual, and understanding the target condition is critical – you have to know where you need to be in order to understand why you aren’t there.  But this is not always easy, especially in fledgling lean organizations.  I believe manufacturing environments in a company attempting to go through a lean transformation are able to understand and articulate a target condition much faster than those in the office or product development organization.  That’s still not saying it’s easy!  But they tend to have more historical data, understanding of their manufacturing process and where defects occur, where their problem modules are and where to focus, and how quality, cost, and production rate have trended.  Many times you can go back several months or even years in the data and say, “oh, we clearly have trended downwards from where we once were”, or “oh, we clearly made an acute shift in June, you can see it right here on the timeline”.  It’s much easier to do this step when you have relevant data available, and when you have people who know how to mine it.

But take for example people in an organization dedicated to innovation, who are attempting to do a kaizen event.  Many times the most difficult question is “what should the target be?” because you don’t have a database telling you what the health of your innovation process is, or how many defects that process produced over the past 3 months… or even a clear definition of what a defect is!  The same holds true for most office processes:  there simply is not a plethora of data to sift through in order to identify targets and potential causes.  So in these types of kaizens, either as prework or as a part of the kaizen itself, sometimes the group must develop a system to measure what is going on in order to even understand if they really have a problem!

So back to step 3 – “Set a target condition”.  I just like the meaning of the process behind this so much better than something along the lines of “What is the target condition?”  Asking “what is it” implies that there IS one out there in your organization and you either don’t know it or can’t find it.  The concept of “setting” a target condition seems to empower the group to define what that target should be:  either because they know what it should be, or because they decide to set a target that corresponds with some level of improvement from where they think they are.  And if they are able to do that, they are able to move to the next step!

I haven’t put it into practice yet, but I believe sending that strong message of empowerment to a kaizen team will enable them to align much more quickly in an event, and move forward to defining causes and countermeasures rather than arguing over what the target actually is.  Because no matter what – you’re in that room because something was not up to snuff, and the bottom line is that is doesn’t even matter what the target is – all that matters is that you are not yet where you need to be.

See a great guest post by Karen on Mark Graban’s blog about PDSA vs. PDCA, and another spirited post by Mark himself on the subject.

“Respect For People” Shines Through In Sandy’s Aftermath

My friend Dave shared a wonderful video with me today that I felt really exemplified Toyota’s concept of “respect for metro logopeople”, especially in connection with doing something good for the community.  The video shows how employees of Toyota’s TSSC team went to work with Food Bank of New York and Metro World Child, creating an initiative called Meals per Hour.  Over an 8-week period, they applied several fundamental concepts of lean in order to get more food to more families faster.  They worked on identifying and eliminating waste, and creating continuous flow in both the packing and distribution processes.

What I loved most about this story was that there was no discussion of cost.  No questions about “what kind of return might I get on this investment of time” or “does this save us any money”.  All I heard was that they wanted to try to improve in order to make the job of the volunteers easier, to ensure more families were fed, and to improve the speed at which they provided service to the families.  In the end it states they were able to feed 400 additional families in half the time it used to take.

1 view 1 mealI checked on Toyota’s news release area and found that in addition to improving the process, for every view of the video on YouTube they would donate one meal to the families, up to 250,000.  The response was so high that they increased their donation limit an additional 1,000,000 meals – and it looks like as of today they have already surpassed the million views mark.

I noticed another video about Toyota and the TSSC (Toyota Production System Support Center) partnering with the Tree of Life Clinic in Tupelo MS to apply lean concepts to improve conditions for patients and volunteers.  tree of life clinicThe clinic provides free healthcare to those with no insurance, Medicare, or Medicaid.  Top problems identified were long waits for patients and long workdays for the volunteers.  Patients might have arrived as early as 6:40 in the morning for a clinic that opens at 4:30 pm, to ensure they are seen that day.  And volunteers were staying as late as 10:00 at night in order to get as many patients through as possible and to complete all the paperwork.

By applying several tools and lean concepts such as 5S, process flow mapping, standard work, and eliminating waiting waste between doctor/patient interactions, they were able to improve in those top problem areas.  The results showed an average decrease of 24 minutes per patient, increasing the number of patients seen in a day from 80 to 90, while reducing the volunteer’s workday by around an hour each day.

Tree of Life results

On the Meals per Hour website, there are several more small videos and blog entries by authors brought in to document and add awareness to the issues and impacts on community members.  I only clicked on one entry so far where Vera Sweeney discusses what she took away from TPS principles – “Change your Thinking and Change Your Life”.  She relates a story about a Toyota employee attempting to improve a restaurant’s order accuracy and how she applied a TPS concept or two at home with her family to improve their morning routine.

I think all these stories illustrate and confirm how much waste exists out there in areas where lean thinking is not being applied yet.  There are a lot of gains to be made to improve the quality of life for people and communities – both the workers and the customers, no matter what the business or venue.  And when you consider how long it takes (in years and decades) to build capability in people to see and eliminate waste themselves on an everyday basis… isn’t it time we got started on that journey?

long journey

Continuous Improvement At Le Tour

tourfrance_2013This upcoming Monday is a rest day for the riders in the Tour De France, and boy do I need it.  No, not because I’ve been logging the same number of miles on my bike in the flatlands of Wisconsin as the pros are on the mountain roads of the Pyrenees.  It’s because I’ve been watching hours and hours of coverage on breakaways, attacks, climbs and echelons – and there simply aren’t enough hours in the week to keep up with it all.

I’ll be the first to agree that the majority of people out there aren’t going to be riveted to their seats watching two hundred cyclists ride between four and six hours nearly every day for three weeks.  Even I tend to fast forward through the flat stages to get to the sprint finishes.  But I have a great admiration for the speed, stamina, distance, and effort at which they pound the pedals.  And just turning on the tv and watching the Tour probably wouldn’t have instilled a sense of awe in me either.  It really came after I read two of Lance Armstrong’s books, Every Second Counts and It’s Not About the Bike.  Within those books Lance gave detailed accounts of the inner workings of the training regimen, the strategic planning, and the teamwork necessary to compete at that level.  After understanding more about the intricacies of the sport, you begin to see more in the television coverage than simply a group of grown men out on a long and arduous ride.

This year’s tour is the 100th installment.  There are 21 stages over 23 days, and the route covers over 2100 miles.  Typically the Tour starts off with a flatter stage with no large mountain climbs, seeming to ease in to the three-week marathon.  The flatter stages tend to see a large peloton of riders approaching the finish line, resulting in a sprint to the finish where speeds reach over 40 mph.  Stage 1 in 2013 was a flat stage on the island of Corsica designed to end in a sprint.  It was a fairly uneventful ride, until the riders were around 15 minutes from the finish line, and chaos ensued as one of the team buses got stuck under the finishing line banner.


The bus was wedged in, with its air conditioning system punctured on top.  People seemed to be wandering around trying to figure out a quick fix, but no one had an answer for this unprecedented situation.  The only thing that was clear was that if the peloton reached the finish line and the bus was there… well, it just wasn’t going to work!  Tour officials were forced to make quick decisions on how to deal with the situation.  Their first choice was to change the finish line further up the road, 3 km short of the finish.  Probably a better solution than a big crash or canceling the stage, but the teams had spent months preparing for the right sequence of events leading up to the original finish line and didn’t have a plan for how to win at a different location.

TourBusStuck2You could tell the poor bus driver felt absolutely horrible and helpless in the situation.

TourBusStuck3DriverIn the end, they were able to deflate the tires on the bus, back it out, and open up an exit on the side of the race to get the bus out of the way.  Then the race officials re-adjusted the finish line back to the original location.  As this adjustment was communicated again through the team radios, a crash ensued in the race involving several of the top sprinters, adding more chaos to the finish.  It turned out to be a much more exciting stage than anyone had expected.

So let’s do a little examination of how the bus happened to get stuck under the banner – what were the causes, were standards present and/or followed, and what kind of things can we put in place to prevent a situation like this from ever occurring again.  First off you might ask, why was the bus even driving on the course?  Well, they tend to parade buses and floats and other vehicles through the finish line before the riders reach the end.  And then you might ask, well what about all the other team buses?  Was this bus special and tall?  Why didn’t they run into it?

From what I can make out of news reports, the banner itself can raise up and down, and it usually up for the parade and down for the finish.  The Orica Greenedge bus was behind schedule, and the banner had already been lowered.  Then reports say the driver received instructions to continue moving on.  A comment from a race official stated he needed to stop and request that it be raised.  Clearly, several failures along the way contributed to the unfortunate state of affairs.

So, lean thinkers – do you blame the process or the people in this situation?  The easy road would be to say the driver was inexperienced and should have known better and it was his fault.  But I’d ask, why was the banner lowered before all the vehicles were through?  Why is the banner set lower than the height of the vehicles going through in the first place?

If I were to jump to a solution before truly understanding the cause, several potential countermeasures come to mind.  All vehicles that will pass under the banner should be measured prior to the stage and any potential problem heights should be noted and tracked through the finish line.  Or, all vehicles over a certain height are not allowed to go through the finish line.  You could even come up with a warning measurement system a few hundred yards ahead of the finish line that alerted the drivers and officials to a potential problem based on the current height of the banner.  All of these solutions, if implemented and followed, might very well prevent a similar situation from ever occurring again.

But we can do better.  All of those countermeasures add some form of complexity to the system.  Added steps of measuring vehicles, added technology near the finish line, added people to do all the extra work – each extra simply increases the opportunities for error, especially if it relies on human interaction.  Ask the question, what purpose does the banner at the end of the race serve?  It is a visual cue for sprinters so they know how close they are getting and when to begin their final attack.  It displays the time, presumably for spectators near the finish.  It has advertising for major sponsors of the race.  And I believe it holds timing system equipment and photo finish cameras on the sides.  You could deliver these functions in other ways.  Visual cues could be done with a balloon or soft hanging banner.  Times for spectators could be displayed on a screen not hanging over the finish line.  Timing system equipment and photo finish cameras can still be erected on the side of the course.

Side benefits might include one less large apparatus to erect and take down each day, one less place where mechanical or electrical maintenance is needed, or where other difficulties could occur.  Perhaps the resources used on these steps could do other value-added work instead.

Many times we consider how to counteract a problem we encountered by adding steps to stop it from occurring.  We should step back once in a while from the solution and ask the question – do we even need this in our process?  Is it still relevant, does the customer still need it?  Or can we remove the possibility of defects occurring by eliminating a step.  Can we make the whole process easier and less prone to defects by subtracting rather than adding?

I Came, I Saw, I Problem Solved… I Only Got To A Temporary Countermeasure. Do I Still Feel Worthy Of Lean?

Problem solving to root cause is an important skill to build capability in.  The “why” behind problem solving to root cause is so that you prevent problems from ever recurring again, thus eliminating potential waste from your future PDCAactivities.  Along the way you grasp the situation, take steps to contain the problem so you are still able to provide the product or service to your customers, understand potential direct causes, test the connection from cause to the problem, develop and test a countermeasure (your hypothesis towards preventing the problem from ever coming back), and put measures in place to sustain and check that the countermeasure works and is still in place.  (Yes, this is simply a description of P-D-C(S)-A with a containment step thrown in!)  It doesn’t matter if you’re talking about 4-Step, 8-Step, x-Step or DMAIC problem solving, the fundamental principles are all the same.

Most organizations that begin a lean transformation are already very good at what they think of as problem solving.  A problem comes up, I work hard to understand what caused it, I fix what caused it, and we’re up and running again.  I add it to our troubleshooting guides and therefore if it happens again we will be able to get up and running even faster because we know how to fix it!  And the veteran problem solvers will be able to tell you war stories of all-nighters where hours of investigation finally yielded something they never thought of: a motor wired backwards and turning in the wrong direction, a bit set wrong in the control logic, or an incorrect part sent and installed that looked just like another part but had different guts.  They might call it “stuff that never should have happened if someone else had done their job right in the first place”, because they are still learning what it means to focus on the process and not the people.  And how if only they’d called the expert in the first place they could have avoided all those hours of downtime because he’d recognize the symptoms and connect it to a problem he solved 5 years ago and could have told them exactly what to check and fix.

“Haven’t we worked on this problem before?” and “Didn’t we fix this last year?” are common phrases you might hear that should trigger you to wonder if you really understood the root cause of the problem the first time.  It feels like problem solving deja vu!  You honestly shouldn’t feel bad about it though, especially if you are still at the outset (read: first several years or perhaps decades depending on point or systemic problems!) of your lean journey.  Solving to root cause, so the problem never occurs again anywhere in your organization, is hard.  It can be hard to identify the root cause, hard to rollout countermeasures across groups in multiple global locations, hard to not get distracted by all the other fires you need to fight this week that seem like a much higher priority.

I recently switched cable, internet, and phone service providers from Time Warner to att uverseAT&T, for a whole host of reasons that could be turned into another post on “thinking customer”.  I’m actually very happy so far in a short period of time with what I now have from AT&T Uverse.  It’s not all ice cream and puppy dogs through the switch however, I have had a couple of internet setup issues that have been frustrating, but they’ve actually been more due to lack of knowledge and added system complexity on my end vs. something that was the service provider’s responsibility.

Yesterday I woke up to a new problem.  When I tried to open a web browser, I got an error message from my AT&T wireless router that popped up on the screen, saying “Excessive Sessions Detected.”  It explained that one of my computers had a whole lot of internet sessions going at once, and that it was likely the result of some form of a virus, or malware.  So, my head began doing problem solving.  Target = Able to access the web from all my devices.  Actual = Not able to from one PC.  Let’s continue to grasp the situation.  Check PC #2 – I get the same error.  Check IPhone – I get the same error.  Actual now equals “Not able to access web from any devices.”

Excessive Sessions Warning

Potential direct causes… 1) the error message tells me it may be a virus 2) the error message tells me I may have gaming software causing it 3) could be a problem with the router 4) a power problem or connection problem somewhere in the system 5) something is broken on AT&T’s end 6) my internet cache is full 7) just something weird that requires a restart.

Ok, so let’s try and work through the most likely causes – 2) I can eliminate this cause, don’t have any gaming software going on (sad, I know, I’m a long way from my college and single days!).  4) check to see I have power everywhere – all ok, eliminated.  1) the system error is telling me “virus” is the first place I should look.  So I run a check, and sure enough, it finds two items and eliminates them.  So as I restart my computer my mind is already jumping down the why chain to root causes like, inadequate standard for setting up my antivirus software, or inadequate process for selecting antivirus software.

Computer is restarted, and… nope, error message still pops up.  How about 7) – let’s restart the router and everything else.  Nope, error still there, can cross that one off.  Now it is about time for work, so I eat some breakfast, watch some TV, and off I go.  Midway through the day my wife tells me the TVs no longer work.  So now, new information surfaced that tells me that something in the system is degrading – the problem is getting worse!  So in my head I mapped out how the system worked and where problems could occur (see setup picture below), and couldn’t figure out what was changing to cause the new problems, because most of the TVs don’t run off the router.  Why did they work in the morning and then suddenly not work in the middle of the day?  Now I start leaning towards something on AT&T’s end as the direct cause.

ATT Setup Map

When I got home I hopped on the phone with AT&T, explained the situation and what I’d done so far, and then we went through their troubleshooting guides.  We do a reset from their end, restart computers and routers and DVRs, and the error still comes up. We cleared the internet cache and tried again.  Still have the error.  We’ve now eliminated 5) and 6), and AT&T is out of ideas on their end too.  Their only solution left is to send out a technician tomorrow, and maybe they’ll swap out a router to try and check 4) – the only direct cause we have left on the list.  This disappoints us, because we wanted to watch the new Modern Family!

As AT&T is finalizing the order for the technician, I decide to check one more thing.  On the error message there are two buttons – one says “Do Not Show” and the other says “Continue”.  I had tried “Continue” early on and didn’t get anywhere.  “Do Not Show” was labeled as something you should only click if you think the cause was gaming software 2) which we had already eliminated, and I didn’t want to ignore the error if I really had a problem or a virus.  So at this point I said what the heck and clicked “Do Not Show”.  It asked me to log in to my gateway, I did, and then it gave me a message – “The problem has been resolved.”

docmcstuffinsEureka!  We were now connected to the outside world again!  My three year old would not be without her Doc McStuffins in the morning!  We could watch Modern Family!  I could stream YouTube videos through my TV again!  I was the hero, I had “resolved the problem”!

My lean thinking was gnawing at me though.  I didn’t know what caused the problem in the first place.  I can’t recreate it.  I can’t develop any countermeasures to prevent it from happening again.  And I’m not sure the AT&T person really captured my “solution” in their knowledge database so that they try it with other customers in the future before deciding to send out a technician.  Yes, the problem is contained, and we are up and running again.  Is that good enough for this situation?  Or should I have done more?

Good organizations are very quick to recognize and contain problems, and to get up and running again to avoid customer service issues.  Great organizations have the discipline to spend time working towards truly understanding the root cause of the problem, developing adequate countermeasures, and ensuring waste never recurs.