The AntiSyphus Effect

Death by overwork

Kathleen DeFilippo — Sun, 25 Jan 2009 07:46:33 -0600

For decades (since I was a young child, in fact), I've heard and read about the Japanese work ethic; it's been held up as a model for Americans. What's not often mentioned is the fact that death by overwork is quite common in Japan. It's so common, in fact, that the Japanese have a word for it: karoshi.

Despite my sincere efforts to bring some balance into my life, I struggle not to overwork. You already know this, as I've mentioned it several times, but what you are about to read will demonstrate that it's not just an irritant anymore. (For extra drama, you may want to insert the "Law and Order" scene opening music at each date - in your mind, of course; we don't want anyone sitting nearby to think you've lost your marbles.)

Sunday, 8 July 2007, 3:00 PM

I drop my son off at the airport for his annual trip to spend a few weeks visiting my ex-husband's sister. I plan to spend this time doing things I can't really do when he's with me: stay late at the office every single day. Am I a party animal or what?

Tuesday, 10 July 2007, 7:00 AM

I go to work, feeling slightly under the weather. I have a large group of colleagues and contractors in to kick off a big, expensive project that I'm slated to lead. As the day progresses, I feel worse. In fact, I feel as if I'm getting the flu. Who gets the flu in July? Nevertheless, I'm quite sure that's what's happening, as I feel vaguely feverish, achy, with a scratchy throat and a mild cough.

I head home after work, drink about a quart of iced tead, down some Nyquil, and then go to bed. At 6:30 PM.

Wednesday, 11 July 2007, 4:00 AM

I don't feel any better when I awaken at my usual 4:00 AM. If anything, I feel worse. Uncharacteristically, I call in sick, and then roll over and go back to sleep. Throughout the day I continue to feel yucky, but don't take my temperature and don't call the doctor. After all, I've got the flu, right?

Wednesday, 11 July 2007, 6:00 PM

My buddy, Dave, arrives with some groceries. I'd called him to let him know my plight, and he stopped at the store to get some soup, bottles of iced tea and ginger ale, and more Nyquil. He did this because he and his wife are good friends, and I owe them my life (quite literally, as it turns out). Dave tells me that I look like ass, and comments that I'm really hot (um, temperature-wise, folks; trust me, at this point, there was no one on earth who would've thought I looked hot). Dave suggests I take my temperature, which I do, only to discover that my thermometer is malfunctioning. It has to be malfunctioning, because no one gets a fever of 105.5º from the flu!

Aside: Needless to say, it was my brain that was malfunctioning, because I refused to let Dave take me to the emergency room. I was convinced - absolutely and with total certainty - that I had the flu, and there was nothing any doctor could do to help me.

Wednesday, 11 July 2007, 8:30 PM

After force-feeding me ice water and several aspirin, getting my fever down to 103.5, and eliciting a promise that I would go to the doctor first thing tomorrow morning, Dave leaves. I drink some more ice water, and go to sleep on the sofa watching television.

Thursday, 12 July 2007, 1:00 PM

So much for "first thing in the morning." I awaken at about 10:30, drink some iced tea, then head up to my bedroom to take a shower. I shower, and then lie down for 30 minutes until I have enough energy to get dressed. This? is really not looking good.

I drive to the doctor's office, feeling absolutely drunk even though I haven't had any alcohol other than my once-nightly dose of Nyquil. Nevertheless, I get to the doctor safely.

Doc looks me over, listens to my lungs and my story of woe, and pronounces that I probably have bronchitis, although my lungs are clear (in retrospect, how my lungs could've been clear is beyond me). He hands me a prescription for Biaxin, and is about to send my on my way when he decides to send in the nurse to check my O₂ saturation with a pulse oximeter. Normal range is 95 and up; mine is only 93.

Thursday, 12 July 2007, 3:00 PM

I'm at the radiology lab, getting a chest X-ray. But really, I just want to go home and go back to sleep because I am soooooooooo exhausted from all this effort.

Thursday, 12 July 2007, 5:00 PM

Doctor calls; X-ray indicates I have pneumonia in my left lung. The good news is that Biaxin is the drug of choice for pneumonia, so I needn't worry. The doctor tells me to take my meds and come back for a followup visit on Monday.

Friday, 13 July 2007 - Monday, 16 July 2007

I'm taking my medication like a good girl. I'm drinking plenty of fluids. I continue to feel horrible - exhausted far beyond what I would expect (and sleeping probably 20 hours a day), still feverish (now staying at about 102º), and still feeling perpetually drunk.

Monday, 16 July 2007, 1:00 PM

I'm back in my doctor's office, lamenting the fact that I really don't feel any better. After checking me over, he grabs the pulse oximeter to check my O₂, and discovers that it's 91. Well, this can't be good.

Monday, 16 July 2007, 2:00 PM

Getting another chest X-ray.

Monday, 16 July 2007, 4:30 PM

Doctor calls and tells me that the pneumonia in my left lung has worsened, and I now have pneumonia in my right lung as well. He says it's clear that the Biaxin is not up to the task, and wants me to check in to the hospital.

Monday, 16 July 2007, 4:36 PM

I have a complete and utter meltdown. "Hospital? They KILL people in hospitals! Do you know how many drug-resistant bacteria are in the average hospital room, just WAITING for some sick person to show up? Please, can't you just give me a broader-spectrum antibiotic?" (Did I mention that my brain wasn't quite functioning properly?)

Monday, 16 July 2007, 4:38 PM

Doctor insists that I really don't have a choice - I need to get to the hospital, and I ought to do it soon. I call Dave and ask him to provide driving services, as I'm afraid to drive that distance in my obviously-impaired condition. I then pack up some pajamas, some meditation beads - and my laptop, so I can work.

Monday, 16 July 2007, 8:00 PM

My O2 has been steadily dropping since I got to the hospital. When I arrived, it was 90. Within an hour, it dropped to 88. Now? It's at 85, and I'm not doing well. My pulmonologist comes in for a visit, looks at my chart, looks at me, and says, "Your pulse-ox is not good, you're struggling to breathe, and your complexion is beginning to look dusky; I think we need to move you to Intensive Care until we get you stabilized."

Monday, 16 July 2007, 8:07 PM

I experience another meltdown as I realize:

I am really, really sick; I could die tonight.
My son is over a thousand miles away, and I might never see him again.
My sister is 400 miles away, and just started a new job, so she can't get here.
I may have some good friends, but I am really, completely, and totally alone.

Monday, 16 July 2007, 8:08 PM through Tuesday, 17 July 2007 9:00 AM

I move to the ICU, and I'll spare you the details of the indignity of the Intensive Care Unit. My breathing becomes more and more difficult, despite the IV antibiotics and supplemental oxygen. At one point, every (shallow) breath I take results in a coughing fit. I'm sent to Radiology for a CT scan of my lungs, and given a shot of steroids. Within an hour or so, I'm able to breathe a bit better and finally get some sleep.

Tuesday, July 17 2007, 11:00 AM

My pulmonogist comes by for a visit, and tells me that they were afraid they were going to lose me last night; it seems that my CT scan showed what looked like ground glass in my lungs. His best guess is that I was beginning to develop ARDS, but that the combination of antibiotics and steroids stopped it before it could really take hold.

Aside: Although I had my computer, it was useless - no wireless, and no way to plug into the hospital's network. So I had to attempt to use my cell phone to figure out what the hell ARDS was - I read the first link I found (which I linked to above), and proceeded to melt down again.

Tuesday, July 17 2007 through Friday, July 20 2007

I'm moved from the ICU to a regular floor room at about 3:30 on Tuesday. For the next few days, I have to deal with supplemental oxygen, checks of my O₂ every few hours, near-constant jockeying with my antibiotics (as the team struggles to find an antibiotic combo that will kick the pneumonia without also killing my liver), and really bad food. Thanks to various friends (and my ex-husband, who was far more helpful than I could've hoped), I had lots of reading material, so at least I wasn't bored.

Friday, July 20 2007 3:00 PM

I'm headed home with my driver, Dave, as I've been discharged. We stop at the local drug store to get my 8 prescriptions filled, and Dave wanders to the other side of the store, as far away from me as he can get. Why, you ask? Well, it seems that Kathleen + IVs = bruises. Lots of bruises. (It's clear to me that I could never be a junkie, because there'd be no hiding the track marks. But I digress.) I have so many bruises all over both arms, and am walking so sluggishly (I am still pretty tired, after all), that I'm sure I look as though I've been beaten to within an inch of my life. And folks are looking at poor Dave as though he did it to me. Poor guy.

Present Day

Obviously, I survived my brush with death. The important question here is: what did I learn from this?

For that, you'll need to read the next post. It's a beautiful Sunday morning, and I want to enjoy it with my husband-to-be.

New year, new look, new focus

Kathleen DeFilippo — Sat, 24 Jan 2009 09:59:40 -0600

Well, I've been gone for quite some time now, but I kept the site running for several reasons:

Folks continue to come by and read what I've written (which is really gratifying, so thank you).
I always planned to come back to it at some point, because...
I still have lots to write about.

So, where have I been lo these many months? Well, grasshopper, it's a long story. In upcoming posts, I'll tell you all about how I got sick and nearly died, decided to change my life completely (so as to avoid a repeat performance of getting sick and nearly dying), changed jobs, met a wonderful man (when I wasn't even really looking), became engaged to be married (after nearly eight years being divorced, which - yowza, what an adjustment!), sold my house (without even trying!), and finally decided to return to writing.

I fully expect that my audience (which, in the interests of full disclosure, was probably never all that large to begin with) will have dwindled somewhat, and I'm okay with that. The Internet is truly a 'what have you done for me lately' medium, and I'm sure I'll have to earn an audience all over again.

That said, I've redesigned the blog a bit (okay, so I changed the color scheme - give me a break, okay? I'm busy!), and as the title of the post indicates, I'll be making some changes to the focus of the blog. You'll get to find out exactly that that means down the road. For now, expect to see some very personal writing about some very personal stuff over the next week.

If you're a reader from the good old days, welcome back. And if you're a new reader, just plain welcome!

[sigh] It's good to be back.

More RCA Resources

Kathleen DeFilippo — Tue, 20 Feb 2007 20:53:41 -0600

I started this series ten entries and nearly one month ago. I hope you've been able to take away some useful information; in particular, I hope you've gained an understanding of just how much your business can gain from using RCA to help diagnose business problems and prevent them from reoccurring.

I've developed a real passion for RCA, and although I work in an industry that requires its use, nearly any business can benefit from it. In fact, I suspect that anyone who goes through a few RCAs will find that s/he too develops a passion for it.

Let's recap, shall we?

Root Cause Analysis is the art and science of determining how and why a bad event occurred.
The goals of Root Cause Analysis include learning and preventative action, and not problem-solving or assigning blame.
You can remember the characteristics of root cause using the FERCS test, and the PHaTS Domino Theory can help you remember to dig a little deeper as you conduct RCA.
Conduct RCA by doing the following:
1. Assemble a team to conduct the analysis, and agree on the problem.
2. Identify likely categories of potential causes.
3. Brainstorm on potential causes, and enter them into a diagram.
4. Use the Five Whys (or Five-by-Five Whys) to squeeze as much information as possible out of every possible cause.
5. Create a FERCS matrix to measure the quality of each potential cause.
6. Identify and implement CAPA.
7. Monitor the effect of the CAPA, and document your work.

Additional RCA Resources

This article by James J. Rooney and Lee N. Vanden Heuvel is a terrific resource for RCA beginners. In addition to root cause theory and some background, Rooney and Vanden Heuvel offer example charts you can use as part of the process.
If you're having a hard time selling your boss on RCA, this analysis by Arthur M. Schneiderman could prove helpful.
Bill Wilson has a wealth of articles about RCA on his site.
This article found on the University of Alabama Web site provides more information about how an organization's culture can create problems.
For more information on RCA tools, read this article by Dr. Anthony Mark Doggett.

RCA can help identify and mitigate the habits, assumptions, and management philosophies that lead to problems in your business. A good RCA program is good for business in a number of ways: it can improve profits (by reducing errors); it can improve customer relations (as your customers watch you really fix problems instead of placing bandages on the symptoms); finally, it can increase employee morale (when your employees see that you use RCA to do more than punish them for their mistakes).

Analyze, learn, improve, repeat. Your business will love you for it.

Life after CAPA

Kathleen DeFilippo — Mon, 19 Feb 2007 20:15:59 -0600

Need to catch up? Read the entire series here.

Congratulations! You've analyzed your business problem, identified a root cause, and implemented a CAPA. So now you're done, right? Well, not so much.

Webster's Dictionary lists several definitions for theory. And really, what you've done in the process of RCA is develop theories. You have a good idea of the root cause, and you've developed what seems as though it will be an effective CAPA. But like any scientific theory, your work needs to be proven. Implementing a CAPA is not the end of the process; it's the mid-point.

If you were wondering why I recommended that you focus on one root cause and one CAPA at a time, now you know. You need to test each CAPA to find out if it works; if it doesn't, then you can safely assume that either your root cause or your CAPA is wrong. Increasing the complexity by concurrently working on multiple root causes and CAPAs will make it far too difficult to see if your CAPA is having the desired effect.

I'm not going to get into a lengthy dissertation of how to measure your CAPA; you know your business better than I do. At its simplest, however, is this: if the problem continues, then you did something wrong. If that happens (and it will at some point), gather your team again and figure out the next step: do you want to implement a different CAPA? Was the CAPA you implemented essentially on the money, but needs a bit of tweaking? Or do you need to create a CAPA for a different root cause altogether?

This leads me to documentation. From programmers who don't like to comment their code to managers who fail to document personnel discussions, people hate to document their work. But documentation is a critical part of RCA (as we say in the compliance biz, if you didn't document it, it didn't happen). The reason documentation is so important to RCA is that you might have to revisit what you've done and make changes; if your documentation is poorly developed and maintained, you may find that the team has to recreate some of the work it's already done. And nobody wants to do the same work twice, yes?

In addition to the fact that the team may need to revisit the analysis, you need to consider something else: turnover. People may come and go, but the issues in a given organization tend to hang on; and while everyone will be gung-ho on the CAPA initially, folks tend to get a bit lax once a problem seems to disappear. If this particular problem pops up three years from now (and the original RCA team is gone), think of how helpful it will be for the new folks to have your experience to draw from when working on resolving the issue. The documentation isn't just for you: it's for everyone who follows after you've moved on.

At a minimum, your documentation needs to include:

The fishbone (or other) diagram that illustrates all of the potential causes identified during your brainstorming sessions
The FERCS scoring matrix
Detailed notes from your CAPA brainstorming session

I would also suggest that you develop some sort of system for tracking and trending RCA. You might find that the same types of issues keep occurring; alternatively, you might find that a disproportionate number of negative events are coming from a particular workgroup. The more information you have at your disposal, the more effective you'll be in preventing problems in the long term. And if you can spot emerging problem trends before they become established bad habits, it'll be much easier to resolve them.

Tomorrow I'm going to wrap up with a variety of RCA resources you can visit for more information. And you're always free to e-mail me if you'd like to ask me any questions.

Friday Favorites

Kathleen DeFilippo — Fri, 16 Feb 2007 21:06:08 -0600

Happy Friday! Sit for a spell, and enjoy some excellent writing from the business blogosphere:

David Master of Passion, People and Principles has a thought-provoking piece on business ethics.

Carmine Coyote of Slow Leadership reminds us that what goes around, comes around.

George Ambler of The Practice of Leadership lists seven failings of really useless leaders.

Rocky of Hillbilly PhD asks what motivates people to work (hat tip: Phil Gerbyshak).

Bud Bilanch - the Common Sense Guy - suggests that great leadership starts at home.

Finally, Phil Gerbyshack of Make it Great! gives us a horrible (and yet pretty darned funny) account of customer service run amok.

Have a great weekend!

An ounce of prevention is worth... well, you know

Kathleen DeFilippo — Thu, 15 Feb 2007 20:47:56 -0600

Need to catch up? You can read the entire series here.

At long last, you've completed your analysis, and you're ready to talk CAPA (that's Corrective and Preventative Action, in case you didn't know). Before we begin, I have six words of caution for you: take one thing at a time. You may have several strong root causes that you want to eliminate; however, I recommend that you start with one. If you implement multiple CAPAs for multiple root causes, it's going to be difficult to gauge the effectiveness of each CAPA.

The term CAPA, although it's used as a single entity, refers to two different activities: corrective action and preventative action are not synonyms. Corrective action is problem-solving; it's fixing the immediate issue, and is often completed fairly quickly. For example, if you look at the order entry error I used as an example in an earlier entry, the corrective actions might be:

Apologize to the customer for the inconvenience.
Issue a credit for the amount overshipped.
Arrange for a freight carrier to retrieve the overshipped product and return it to your facility.

And just like that, problem solved. However, you've done nothing to keep the problem from happening again. That's where preventative actions come in. In our example, we concluded that the root cause of this error was the mistaken belief that "everyone" knows that we have to specify the unit of measure on the order entry form, and therefore it's unnecessary to modify the form to request the unit of measure.

Many businesses would suggest that the solution to this problem is simple: train all the employees so that our assumption that "everybody knows" becomes fact. Well, that's probably not the best answer, unless you want to re-train every time someone forgets (and they will), or with each new hire. Mind you, I'm a training professional, so it irritates me no end when folks think that training is the answer to every performance problem. Trust me, it's not.

So how do we prevent this from happening again? You need to think about systems; not software systems, necessarily (although sometimes a software modification is in order), but business systems. Once again, your team members need to leave their egos at the door. This is the time for management to 'fess up and admit that they've contributed to the problem by creating a system in which it's easy to perform the task improperly, and difficult to perform it correctly. If you're a manager, your goal should be to help your employees succeed by making it easy to do their jobs correctly, and difficult to do them incorrectly. Only after you've helped remove their obstacles to good performance can you reasonably hold them accountable.

You'll identify CAPAs in the same way you identified possible causes: brainstorming. If you were able to score the "fixable" quotient of the cause, then you've probably thought of possible CAPAs as part of that process. Now you'll flesh them out a bit more. When you're developing CAPA, there are a few questions you'll want to answer:

Who owns the change(s) we're putting in place?
Whose jobs will be impacted by the change(s), and to what degree? How do we communicate the change(s)?
Do we need additional resources (human or capital) to effect the change(s)?
Who will resist the change(s), and how can we overcome that resistance?
How much will the change(s) cost, and how long will implementation take?

And the most important question of all: how will we know if the CAPA(s) work?

Tomorrow I'll post this week's favorites; Monday I'll cover monitoring CAPAs and documentation, and I'll finally wrap up this series on Tuesday. Have a great evening!

You can't always get what you want

Kathleen DeFilippo — Wed, 14 Feb 2007 20:38:33 -0600

In honor of Valentine's Day, I think it's appropriate to write about finding your perfect match. No, I'm not referring to dating; I'm referring to hiring. Your success as a manager depends at least in part on your ability to hire well. A good team can make your job easier than you ever dreamed; a bad team can spell doom for your career.

The first key to successful hiring is found in the job description; a good job description (read: realistic, detailed, and measurable) makes the entire process flow more smoothly, because it tells you exactly what skills and attributes the candidate needs to have. A good job description also provides an accurate representation of the job to the potential candidates, which helps them make an informed decision when you make an offer. But most job descriptions (at least, the ones I've read) are not good by those definitions. In fact, most folks seem to have more realistic, reasonable criteria for a potential Saturday night date than they have for the person who's going to be responsible for keeping the books. You can't get what you want if you don't define what you want.

Responsibilities

Document the responsibilities this person will have, and the tasks s/he'll perform. Put down everything; you can filter later if necessary. Is this person going to manage others? Write code? Develop documentation? Analyze data? Facilitate meetings? What does a typical day/week/month look like? If there's another employee who already performs this job, ask her for input.

Requirements

Now that you know what this person is going to do, you need to identify the skills s/he'll need to do it. This is where many job descriptions fall short. You need to define the requirements for the job in the same way you'd communicate expectations to an employee: the requirements should be clear, specific, and measurable (or, in the case of soft requirements like "strong communications skills," objectively identified in some manner). It's important to be clear because ambiguity breeds frustration in recruiters; if your recruiter thinks that "good interpersonal skills" means extreme diplomacy when what you really want is someone who's direct to the point of bluntness, your recruiter will soon start pulling his hair out after you shoot down candidate after candidate. Here are a few examples of poorly-written requirements, and better ways to define them. For the record, these all came from actual job descriptions.

Don’t write this	Instead, write this
Æ Strong written communications skills	© Writes grammatically, clearly, and appropriately for the audience
Æ Self-directed	© Able to prioritize workload and manage responsibilities with little to no supervision
Æ Strong computer skills	© Able to create PivotTables to analyze data; able to use advanced functions of Excel; can use styles, fields, and protection in MS Word to develop templates and forms.
Æ Must demonstrate exceptional organizational skills	© Able to track and manage deliverables for up to 20 projects simultaneously
Æ Strong followup skills	© Communicates with resources on a weekly basis to monitor project status; updates key stakeholders on a monthly basis

In addition to these documented requirements, you'll probably have some other key attributes or personality traits that you think of as deal-breakers; these might include strong ethics, creativity, the ability to play well with others, and other characteristics that are difficult to quantify. That's okay; when we get to interviewing, I'll help you figure out how to separate the good interviews from the good candidates (hint: the best candidate is not always the person with the fastest, smoothest answers).

Before I send you on your merry way to spend the rest of the evening with someone you love, I want to caution you about another requirements pitfall: Know and clearly define the "must-haves" vs. the "nice-to-haves." Is it really necessary for the candidate to have an advanced degree in Medieval History, or will any History degree (or a different degree, or 8 years of related experience) suffice? Does your technical writing candidate really need to know your particular obscure desktop publishing application, or will you accept a great writer who needs to learn the software?

Keep in mind, there are no wrong answers here; you can make your requirements as stringent as you like. However, if your requirements are very narrow, then A) your pool of qualified applications could be very small, and B) you'd best be prepared to pay a premium salary.

In Part II of this series, I'll help you sift through the piles of resumes you've received, and give you tips on preparing for your interviews.

You take the good, you take the bad

Kathleen DeFilippo — Tue, 13 Feb 2007 21:02:24 -0600

Need to catch up? Read the entire series here.

Now that you have a comprehensive schematic of possible causes - and you've delved into each possibility to get to the hidden assumptions that may be driving those causes - it's time to start filtering your options. While it's entirely possible that the scenario you're analyzing could have more than one root cause, you can't fix everything at once; you need to prioritize. In addition, you need to throw out the red herrings. Remember, in the first phase of this process, you accepted any and all possible causes; now you have to take the opposite approach and make each possible cause fight for its life.

You may be wondering how on earth you're supposed to start filtering through the dozens of possibilities, and the answer to your question is this:

Put all the possible causes to the FERCS test.

You remember the FERCS test, don't you? It identifies the characteristics of a root cause.

"But Kathleen," I hear you cry, "how does this test help when there might be a lot of possible causes that meet all of the FERCS criteria?" Ah, grasshopper, what you must do is measure how well each cause meets the FERCS test. To do this, plug the possible causes into a matrix that lets you score them against the criteria.

Rather than make you come up with your own, I've designed a simple matrix that you can download and use freely. The file is an Excel workbook that uses a weighted average score, with the fixable, explains the bad event, and controlled by management scores weighted twice as heavily as the remaining criteria. I've weighted the scoring in that way because my experience has demonstrated that those criteria are the key players in RCA. The tool helps you measure the quality of each cause, and move forward accordingly. Identify a minimum passing FERCS Score, and then eliminate any causes that don't meet that minimum score.

By now, you should have narrowed down your list of possible causes to the mostly likely culprits that are also those you can reasonably expect to correct (and prevent from popping up again). The next post in this series will address developing CAPAs.

Channel your inner two-year-old

Kathleen DeFilippo — Mon, 12 Feb 2007 12:09:35 -0600

Need to catch up? You can read the entire series on RCA here.

At this point of RCA, you should be looking at a diagram filled with possible causes. But you're not done yet: this first pass of brainstorming tends to yield physical and human causes; in order to get to the top-secret causes, you need to dig into each of the causes you've identified thus far.

If you've ever parented a toddler, spent time with a toddler, or been a toddler, you'll know that the period known as "the Terrible Twos" is defined, at least in part, by what seems like constant curiosity. Annoying though it can be, the average toddler's tendency to ask "why" until your ears bleed is a habit you'll want to borrow in this phase of root cause analysis.

This technique is referred to as the Five Whys. Don't be misled - five is not a hard and fast number here; you might need to ask more than five times (or fewer). The point is to continue asking why until you get to what's really driving that particular cause. For example: you're analyzing an overshipment of widgets; among the possible causes is "Customer Service Rep mis-keyed the order quantity." Your mission, should you choose to accept it, is to figure out why.

So, why did the CSR mis-key the order? Because s/he thought the order was for 10 cases, when it fact it was for 10 eaches.

Why did the CSR think that the order was for 10 cases instead of eaches? Because the customer didn't specify the unit of measure on the order form he submitted.

Why didn't the customer specify the unit of measure? Because the order form in place doesn't have a space to enter unit of measure.

Why doesn't the current order form ask for unit of measure? Because it's an old form from our previous system (which used only one unit of measure for ordering), and the form hasn't been updated.

Why hasn't the form been updated? Because updating the order form is not considered a high priority.

Why isn't updating the order form a high priority? Because everyone knows that we have to specify the unit of measure in the order entry system, or all orders will default to case unit of measure.

Okay, so that took six whys, but we got to the top-secret cause, didn't we? If we can convince ourselves that "everyone" knows that they must specify the unit of measure (and apparently, that's exactly what we've done), then we don't need to go to the trouble of updating a form. These types of assumptions drive more business inaction than you might think - and consequently cause more problems than you might think.

If you want to take the Five Whys to a deeper level, you can use the Five-by-Five Whys. I find the Five-by-Five Whys to be a terrific tool in RCA, because they can help you both identify latent causes and filter your list of causes as you go, thereby helping the process move a little more quickly.

Friday Favorites

Kathleen DeFilippo — Fri, 09 Feb 2007 08:57:39 -0600

It's Friday again, and we all know what that means: time for Friday Favorites!

Pamela Slim of Escape from Cubicle Nation has two big pieces of news.

Guy Kawasaki of How to Change the World gives us The Asshole Rating Self-Exam.

Penelope Trunk of Brazen Careerist, keeping with the self-diagnostic theme, shares tips on recognizing your inner nutcase.

Have a great weekend!