The AntiSyphus Effect

More RCA Resources

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

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

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

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:

1. Apologize to the customer for the inconvenience.
2. Issue a credit for the amount overshipped.
3. 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

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

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

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

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!

Measure what matters

Several weeks ago, I spoke to a friend who lives back home in New Jersey. He vented a bit of frustration at his employer, a law firm in Manhattan; it seems that one of my friend's colleagues had been terminated - because he'd been late to work one time too many. On the surface of it, that doesn't sound so unreasonable; but that's only part of the story.

You see, this particular employee - we'll call him Joe - worked in the IT department. For the last six months of his two-year tenure, Joe was performing both network connectivity and database administration (functions that, in most organizations, are performed by two different people). In addition, Joe lived in Queens and drove into Manhattan every day - a commute that is notorious for its insanity. Finally, Joe regularly worked from home well into the evenings.

Let's recap: you have a single employee who is doing the job of two; he willingly works on his own time to ensure that business flows smoothly. He's a terrific employee, but he has a problem getting into the office on time. So what's more important: facetime? or effectiveness, productivity, and passion for the job?

This law firm made a bad call here, if you ask me. Sure, there are industries and businesses where facetime and punctuality are critical. My sister is the Director of an ICU, and nursing is a profession where punctuality is absolutely necessary: nurses give report to the next shift during shift changes, and so being late can mean the difference between knowing what's going on and operating blind. But for many of us, in many businesses, facetime is something we use as a means to control our employees for no good reason other than the fact that we can.

This is a stupid way to operate, folks. Facetime is not an effective measurement of an employee's value - particularly if the employee is salaried rather than hourly and has a notebook PC and remote access. These days, lots of employees have cell phones and remote access, making them reachable nearly all the time. And people want some flexibility in their work lives; if I'm going to be checking e-mail at 5:00 AM, I expect a little bit of slack when it comes to leaving the office a few minutes early.

By creating a culture in which facetime is everything, businesses do themselves and their employees a disservice. Employees who might otherwise work from home or answer their cell phones after office hours will, when faced with a facetime-is-all environment, decide to stop answering those post-5:00 PM phone calls. They'll be a little less likely to log in to do just a bit more work in the evenings. On their days off and vacations, they definitely won't be willing to take calls from the office, because the office has made it clear that it doesn't value their time. And their passion for the organization will wilt away. Ultimately, they'll leave the company to work for businesses that measure what matters. Until then, however, they'll be clock-watchers: there on time, out on time, and probably not terribly productive in between.

If you say that you value your employees' work-life balance, and you say that you want people to want to work for your company, you might want to take a look at your policies around facetime and see if they are congruent with those values. Unless it really matters, don't try to control your employees with the timeclock. In fact, don't try to control them at all; instead, manage them according to what's important. Value their time, and they'll value yours. Give them flexibility, and they'll reward you with loyalty and greater productivity.

People will pay attention to what you measure: do you want your employees to focus on the clock, or do you want them to focus on being great at what they do?

Let's meet to talk about meeting to plan the meeting...

I often say that meetings are the lifeblood of bureaucracy. I don't know anyone who enjoys meetings; and yet, we seem to have 'em all the time. I probably spend the equivalent of one full day or more each week in a conference room.

As much as I dislike meetings, however, I know that they are a necessary evil. So I'd like to share a few tips to help make your meetings a little less painful for all involved.

If you're hosting a meeting

• Identify the goal of the meeting: Are you gathering suggestions for an upcoming project? Is it a working meeting in which you need to get something done? Is the meeting simply to share information?
• Write an agenda for the meeting, and share it with the participants: I hate it when I'm invited to a meeting and have no idea what it's about. Share the goal and the agenda with the invitees. The agenda doesn't need to be a minute-by-minute, detailed map of the meeting; but a stated goal and topics of discussion would be a welcome change from an invitation with no explanation.
• Invite everyone who needs to be there, and only the people who need to be there: This should be a given, but I've gone to far too many "bloated" meetings to think that everyone operates under this premise. Don't make your meetings any larger than they need to be; alternately, don't leave out any key personnel.
• Start the meeting on time: Don't punish the people who show up on time by making them wait for the latecomers. If you get a reputation for starting on time, people will start to show on time, I promise.
• Keep the meeting under control: Use a flip chart to establish a parking lot; if someone brings up a point that's outside the scope of the meeting, write it in the parking lot for future discussion (instead of getting bogged down in an off-topic discussion).
• End the meeting on time: People are busy, and my experience is that most people are too polite to get up and leave a meeting that's still in session - even if that means that they're going to be late for another meeting. If you can't wrap up in time, schedule another meeting if you must; but don't hold everyone hostage.
• Wrap up with action items and next steps: If any tasks come of the meeting, restate them in the closing. Then, send out minutes that document the action items.

If you're attending a meeting

• Get there on time: If you accepted the meeting, then be prompt. And if you can't make it on time, then call the host and let her know you're going to be late.
• Participate: Don't fall asleep (I've seen it happen), read e-mail on your BlackBerry, or sit there like a lump. You were invited because your participation is needed, so be willing to share your knowledge.
• Put your cell phone on vibrate or turn it off: If you're expecting a call that you know you'll have to take, let the host know. Otherwise, ignore your phone and focus on the task at hand.
• Leave on time: If you have another commitment, don't stay past the appointed hour (thereby making yourself late to your next meeting). There really isn't anything wrong with saying, "Sorry, but I've got another meeting, so I have to duck out."

Stick to these basics, and you'll find that meetings will become a joy. Well, perhaps that's a slight exaggeration; stick to these basics, and meetings will become more productive and less painful.

What are your tips for making meetings worthwhile?