use a few tools from my lean/six sigma training to make my personal life easier. If you’ve read “High Reliability Camping,” you know that I have a method to prevent packing mishaps by using checklists. I’ve also utilized the “Set in Order” pillar of 5S in lean methodology to design a large tote with my base camping gear stored in a consistent and easily retrievable way. At the end of the trip and packing my gear to go home, I clean each item and return it to the appropriate place in the tote so that I’m already set to go on my next adventure.

Easy and highly reliable—until last weekend when my system was tested out in the middle of a Southern Utah desert and I didn’t have a tent. 

The weekend turned out great and I was able to share a tent with a friend but when I returned home I was frustrated that I forgot an essential part of my camping gear. How did this happen to my high reliable system? 

Jumping to solutions

My immediate thought was that I need to go through my checklist every time and through my standardized tote. However, the reason I have the tote is to reduce my prep time for camping. Changing my process to go through the checklist every time would increase prep time. Maybe I should just get rid of the whole system and figure out another way because it didn’t work. I realized that I was jumping to broad solutions and hadn’t really addressed the “Why” of the failure. So I took a step back and started asking “Why.” 

Start with Why

I started with the obvious: Why was my tent missing? I found it on the garage floor. Finding my tent on the floor triggered a memory that a friend had asked to borrow camping gear. I hadn’t designed a process that accounted for someone else borrowing my gear and now I knew that all I had to do was add a process for when someone borrowed gear. I added another step to process: go through the checklist immediately after they return the gear. So far I haven’t had an opportunity to test my system but I’m not worried about it because I know the system has decreased the number of mishaps that I had from before I implemented it.

No really, start with why

We can see a similar pattern in health care. A process is functioning, then there is a failure. We tend to want to fix the failure with our first solution, instead of asking why. For example, I was asked by a team to fix lag time responding to patients. The first proposed solution was to hire an additional medical assistant (MA) for the clinic. Even after adding a half FTE MA, the response times did not improve.

We can see a similar pattern in health care. A process is functioning, then there is a failure. We tend to want to fix the failure with our first solution, instead of asking why.

By taking a closer look and talking with the MAs, we were able to address the “why” of the problem. The MAs were responsible for memorizing seven non-standard ways of contacting the surgeons with patient questions. Relying on memorization alone leaves a lot of room for error.

To improve this process, the clinic team identified the most common questions, provided guidance on questions that could be answered by the MAs, and standardize the communication response times. The new process was implemented and the MA’s were empowered to triage the messages. The process reduced the number of messages that needed a surgeon’s response, reduced the number of incorrect responses, and reduced the time to respond to patients.

By taking a step back and using a root cause analysis tool like “5 whys” a team can address the underlying issue to create a high reliable process by fixing it once rather than placing a stop gap solution in place.

We cannot foresee all the potential causes of failure but we can try to design reliable process by using proven tools such as a checklist, 5S, or standardization and then continue to improve on these processes as failures arise by using root cause analysis tools like “5 whys”, and fishbone diagrams. Until then, happy camping.

*Originally published August 2, 2019