Success-hack: Using an Issue Log to Improve Personal Performance

Are you interested in what makes certain people and organizations more successful than others? Have you ever wondered what they do differently than you?

I don’t believe there is one magical formula, but I do think there are certain tactics that successful organizations and people have that contribute to their success.

One such tactic is an “Issue Log“. I’ve recently started using one, but haven’t carried it out completely within our organization. I’ve made it a personal objective to use it in 2013,  and I’ll report back on the results and lessons learned soon.

What’s the Idea in a Nutshell?

In brief: Organizations (and people) make mistakes. This happens to everyone, every day.

Instead of making those mistakes and just letting them pass by, an Issue Log is a device an organization/team/person can use to get at the root of why the problem happened, who was responsible, and what steps are required to prevent similar situations in the future.

The theory is that in the long run, organizations (or people) will learn to address issues at their core instead of just at the surface, and therefore improve their ability to meet their objectives.

When Rahm Emanuel was President Obama’s chief of staff, he once said something like: Never let a good crisis go to waste.

The premise behind an Issue Log is the same: instead of fighting through difficult problems, and then letting them become memories once they die down, document the crisis (or ‘issue’ if you want to be less dramatic), and be very specific about what happened and what will change to ensure that it doesn’t happen again.  Don’t waste an opportunity to learn.

Issue Log Format

Here are the columns I have in the Issue Log, a brief description, and a fictitious example of how they might be used:

• Date/Time: Self-explanatory.

• Description: A concise overview of the situation/issue, with the name(s) of those responsible for the involved activities; example: “Dave accidentally published a blog post before it was ready.“

• Why it Happened?: A concise description of the root-cause. This may take some time and discussion to arrive at; often the first reason you hear is not the real reason, so you’ll need to push further.  Example:  “Dave accidentally hit the PUBLISH button because he was trying to work too quickly and didn’t take the time to check his work.“

• DRI: An abbreviation for the “directly responsible individual”; in this case “Dave“

• How Will We Ensure This Doesn’t Happen Again?: The very specific next step(s) and action owners required to safeguard against the incident; example: “Dave’s permission to PUBLISH will be removed, requiring John to proof the post and PUBLISH.  Having a  two-step process should address the issue.“

How to Use the Issue Log

As incidents occur, they should immediately be added to the Issue Log, and time should be set aside to do the appropriate follow-up.

In order to get everyone comfortable with the idea, you’ll need to remind them that the purpose is not to point fingers; rather, it is to accept that mistakes happen, and that they are valuable teachers if the right process is put in place to (a) maximize their instructional potential and (b) ensure that they don’t happen again.

It is probably difficult and a bit awkward at first, as most organizations (and people for that matter) are often not comfortable talking about mistakes.

Many suggest that you also publish the Issue Log for everyone to see and read, so that the organization as a whole learns from its mistakes.  I think this can be a powerful tool for communicating best-practices and lessons learned that benefit everyone.

What do you think of using an Issue Log?  Have you used one?

If not, does it seem harsh?  Since people may view it as being publicly reprimanded, will it create a culture of fear?

Or, if used appropriately, can it help an organization learn from mistakes?