DailyKaizen

I’ve been reading a bit about the software industry, which parallels health care in so many ways, I am finding. One of the things I hear (or is implied) is, “we just can’t do LEAN (or name your improvement effort) at organization x.” We also feel the disappointment in the times when we don’t quite communicate right (per Lee and my recent entries here).

I found this quote in a blog entry from a Python language programmer encouraging his Java programmer colleagues to be flexible in their thinking. In a strange way, it paralleled in my mind some of the thinking we bring to quality improvement, in terms of needing to reflect on our instincts, and in believing that we can solve problems with what we have within us. This all may make no sense to you - it was a bit of a stretch for me, but I liked it nonetheless.

Essentially, if you’ve been using Java for a while and are new to Python, do not trust your instincts. Your instincts are tuned to Java, not Python. Take a step back, and above all, stop writing so much code.

To do this, become more demanding of Python. Pretend that Python is a magic wand that will miraculously do whatever you want without you needing to lifting a finger. Ask, “how does Python already solve my problem?” and “What Python language feature most resembles my problem?” You will be absolutely astonished at how often it happens that thing you need is already there in some form.

For those of you that are consultants have you ever had a meeting with a client where you really wish you could start all over?  That is exactly what happened to me today.  My job is to help bring clarity and new knowledge/perspective to others work.  I had a meeting today where I only confused and frustrated those that I was trying to help.  As I walked out of the room I realized just how far off I was and it must of sounded like I was speaking french.

Why?  Mainly because I was not able to put myself in the shoes of those I am trying to help.  The group I met with today is one of my favorite client groups of all time and is one of the first groups that I ever worked with as a green consultant.  A while back I helped this group get started with some basic training and a single RPIW.  Since then this group has done amazing things on their own with very little support. I really respect their courage and their willingness to keep going.  On occasion I meet with them to give them a consult as they continue to progress with their work and today was one of those days. 

Since the last meeting with this group I have been deeply engaged in the Model Line work and my level of competency and knowledge has expanded, but I guess I have forgotten my consulting skills along the way.  Today this was evident.  From the very start of the meeting I was making statements that would only make sense to those that have been along on the journey with me.  I was trying to describe how to complete a Value Stream map for a complicated IT process and all of the examples I provided required first had experience to understand.   By the time the meeting was over I could tell that they couldn’t wait to get me out of there.  It is a big lesson learned.  To be a good consultant I need to understand where my clients are and come to them as opposed to trying to get them to come to me.

As I mentioned in post yesterday as well as a couple of times last week we had our final Hoshin planning session Friday for the Model Line and we are now ready to begin the process of deploy, check and adjust.  This weekend I was filled with mixed emotions about the day.  For the first time possibly ever we have a realistic plan in the Division that details both the ends and the means.  Everyone in the room was excited and would agree that it was the most useful planning process they have been through.

On the other hand I struggle with my inpatience.  We are so inexperienced and so unsophisticated.  While any good strategy is made up of half analysis (facts and data) and half intuition (from the gut) we were forced to rely mostly on intuition even though we have spent months collecting data.  Why?  It is the old chicken and egg statement.  Without having a Lean Management system are not collecting the right data in most cases and we don’t have a good view of cause in effect.  As a result, we have a twelve month plan, but only confidence in the first three months. 

I guess this is okay.  Our goal should be to get better and build the systems so we have better analytic capabilities and are able to extend the reliability of our plans further each month.  It will be an interesting year of PDCA…

I received a great e-mail message from Mark Graban, from the highly respected Lean Manufacturing Blog, where he said the following

I read your blog post… I think I got the gist of what you were saying…. why would you necessarily want “one piece flow” for ideas from people? You’re really saying “don’t tell us now, we’re at capacity??” That doesn’t seem right….I think your blog post either said, or I misinterpreted, that you were telling people to NOT make suggestions because the capacity wasn’t there.

The concern is well taken, especially after reading about all of this community’s commentary on LEAN implementations with varying degrees of philosophical adherence to the model.

To be a bit more disclosing, at one point in the conversation that I talked about, I did make that implication, and then immediately retracted my words because I realized it came out wrong. That says something about how easy it can be to drift to a disrespectful place (and also how we can never be perfect, but we can learn to recognize our imperfections more quickly…).

Continue Reading »

As I mentioned last week we had our final Hoshin Planning retreat this last Friday for the Model Line.  It was a challanging, sometime frustrating, but overall exciting day.  At the conclusion of the day we had a single plan that all of the leaders support and is ready for deployment.  Being our first year we are very green and have many gaps in our process and our knowledge.  For example, we have decided to only play catchball one level down in leadership, we did not have a formal reflection process this year, and our ability to get useful process metrics is lacking.  Yet, everyone in the room would agree that it was the most useful planning process they have ever been through.  

 We have also agreed as a team that for the 2008 planning and management process we would continue to evolve and expand the process.  For 2008 we plan on conducting a formal reflection process.  We plan on playing catchball down to the manager level and we plan on bringing in leaders from other division to help with our goal setting process.  Our goal is to get better each year and to continue to build our planning and deployment skills at all levels.  We cannot claim success until our planning and deployment process transcends the entire organization creating a line of site all the way to the associate level.  In this spirit here is my quote of the week from Shoichiro Toyoda about Policy Deployment:

“It’s also important that the system proceed on the basis of shared views between the team determining objectives and actions above and the individual units or individuals below.  That’s why, at Toyoda, we decide these things through exhaustive discussions in study sessions or off-site retreats.  Merely communicating through documents will give you a kind of policy deployment in form only, long on work and short on results.”

Without infringing on Lee’s Quote syndicate, I’d like to offer this from Linus Torvalds, from Businessweek, in 2004.

In science, the whole system builds on people looking at other people’s results and building on top of them. In witchcraft, somebody had a small secret and guarded it — but never allowed others to really understand it and build on it.

Linus was talking about open source vs. proprietary software. In health care and health care information technology specifically, there has been a bit of a witchcraft mentality. Our patients benefit when we replace witchcraft with science, not only in the treatments we recommend, but in the way we provide those treatments.

Last week, we took a product that we created as part of our clinical information system to a health care team (nurses, doctors, and support staff) to make it better. And they did. Very quickly. We showed them the limits of what could be done, and they went with it, with our team fixing and improving on the spot. They understood what we had done and built on it to make it better. Exactly as our patients expect.

I am curious about the reaction that Art Bryne received when he said this to some of Wiremold’s suppliers. My guess is that it wasn’t universally positive.

I have struggled with this concept here. Yesterday, I attempted to explain it to a group of physician colleagues, with the analogy that their ideas for improvement were inventory. For the purposes of telling the story and being as honest as possible, I’ll say that my success in doing this was fair to poor. The question came regarding our ability to accept input for changes, and why, using a one piece-flow design, we would not be able to continuously accept input, maintain an list, and then work down the list as we go.

This led to an attempt by me to explain LEAN in about 30 seconds, with a very cordial discussion following, but a less satisfying feeling at the end than I would have liked.

I have had similar interesting experiences explaining this concept in other areas - that it is ultimately not in the best interest of the organization for one unit to create a production calendar that is isolated from the other value-added portions of the organization. I have worked to explain that there either needs to be synchronization (better), or no hand-off at all, with the expertise localized in one area or person (best).

I suppose what I can take from this educational experience is the opportunity to create a small teaching module on one piece flow in health care, not from the clinical delivery perspective (e.g. flow of patients), but from the system improvement side (health information technology).

The silver lining on all of this is that a large integrated delivery system affords many opportunities to test out educational approaches until the right one is reached.

The organization I work in is unique in today’s healthcare market, because we are one of the few remaining staff model HMO’s.  This means that not only are we the insurance carrier we are also the providers of healthcare.  Further, most of the physicians that provide care for the organization are employees.  This provides us a unique set of opportunities if we are able to capitalize on them sense we have different incentives then other insurers or providers.   Primarily, in order to be effective we need to focus on preventive (proactive) care as opposed to dealing with acute problems (reactive).

I am currently working with a small team that is value stream mapping the entire process of care around a specific type of benefits/services.   Like all healthcare organizations we have complex processes and challenges with linking departments and flow patients, information and products.   Yet, even though we have just begun this data collection process it is energizing how much opportunity there is for us to do amazing things for our patients/members that other organizations cannot do, because they are not organized like we are.   Through Lean thinking I believe we can make this happen.  Our success will be determined by our ability to simplify and align our administrative processes around our core clinical value streams.  People need insurance so that they have access to health care and for no other reason.  Really, there is no value added insurance steps.  The only value added steps are those where people are accessing care, or don’t have to because effective prevention practices have occurred.   Thus as we move forward in our Lean journey we need to find ways to make the insurance part of our business seamless or even invisible to our members to that we can focus our energy on what really maters: keeping people healthy!

As a consultancy we have been working closely with several managers in assessing the current status of their Quality Assurance systems.  Like most organizations we many processes that have an audit function that is located at the very last point in the process within the function.  There is typically two reasons why we audit: to ensure that we are not passing defects downstream and to catch mistakes in order to measure and hold individuals accountable for their performance.  By its very design an audit function is reactive since the problems have already occurred and we are now attempting to catch them.  Additionally, holding individuals accountable for process issues leads to many forms of waste as well as a culture of hiding mistakes.

In a couple of these functions we are changing the focus of how we utilize the audit function and are doing some experiments.  First, we are moving the audit function into the team and having audits take place in real time.  The purpose is no longer to rate people’s performance, but instead to identify process problems or training opportunities.  Our goal is to make the audit proactive so that we can error proof and build team competencies.   Second, we are establishing production system audits where senior leaders gather data and conduct gemba walks to identify the capability/reliability of processes.   The goal is to get better every day and set up the right incentives to promote proactive work whenever possible.  These are big changes and have been met by different levels of resistance, but I am confident it is the right work.

What if you were the steward of an information system that could improve outcomes, affordability and the care experience if implemented and managed well, and do the opposite if not? It’s likely that you would be working with a lot of smart people who would do their best to assure the former, rather than the latter use of the tool.

We are transitioning to a hoshin process for planning enhancements to the tools we have in place for the purposes above. In an organization with a lot of smart people, there is no shortage of ideas, which I consider to be a form of inventory. We are hoping to do this process every 90 days, which gives us a chance to make adjustments and improvements fairly frequently.

As the official medical steward, there are things I believe have the best impact on the goals we want to achieve based on what I know about the system. Should I therefore have my own “side door” to prioritize the things that I think are best done with our limited resources?

I have thought about this. I believe in most information technology organizations of the non-LEAN variety, the side door is the state of affairs. It’s assumed that the stewards know best what is relevant to the customer and will execute a plan based on this knowledge. Sometimes this knowledge is gained second hand, though.

What I think about with my LEAN hat is something different. What if I use the front door instead, and treat my ideas as inventory to be respected along the ideas presented by operations leaders and those closest to the customer? This would mean spending some time (some nemawashi) to align the “why?” of my ideas with those providing direct care to the member. In some cases, the thing I think has the most promise might not get prioritized. At the same time, if I make the effort, and the idea gets prioritzed, I think there’s a greater chance of success because we are prioritizing together.

Should I put a lock on the side door and ring the doorbell to get into my own house? In this case, the house really isn’t mine; it belongs to the members, so I think it is incumbent on me to enter it with the other guests. Once we get inside, though, I am sure I will be able to cook a terrific meal, because I know how to use the kitchen really really well.