Learning from mistakes is not an easy task to accomplish

It is common to read that we should learn from our mistakes. It is absolutely true. The problem when we talk about mistakes is to learn how to recognize a mistake, and which lesson we can take from it.

Although it seems a simple task to accomplish, it is one of the hardest to do.

Recognize a mistake

The mistake analysis is a serious thing.

First of all we should be able to recognize a mistake

Then we should analyze what kind of mistake we are dealing with

After we understood what the mistake is we should try to find out which lesson we want to take from it in order to avoid to repeat it again.

But it is not always so easy to recognize a mistake. Sometimes a thing goes wrong and we do not understand why, we focus mainly in find someone to blame or the guilt.

Causes or symptoms?

Sometimes it can seem simple to understand what a mistake is, the truth is that most of the time we are not actually able to understand the difference between the cause and the symptoms of a mistake. Looking in the wrong direction can make us think the symptoms is just a cause, this way we will never learn a lesson, but we will add new problem for the future.

To understand the point think about what a doctor should do to diagnose an illness. Sometimes what can seem a cause is just another symptom, so maybe you see fever as the cause of your debilitating, but fever is caused by what? By an infection may be? Or by something else? Looking for symptoms even apparently unrelated is, usually, the way to discover the root cause of your illness. Addressing symptoms without a proper analysis can drive you to the wrong diagnosis.

Do not look for someone to blame

The first rule when something goes wrong is not to find a guilty, someone to blame. It sound incredible but find a guilty will not help you to address the problem.

Sometimes people make mistakes because it is forced to from external factors, sometimes are just honest mistakes, sometimes is done for negligence, sometimes for will to damage.

No matter what is the reason our task is to understand:

What happened?
What went wrong?
What can we do to minimize the impact?
What can we do to address and fix the problem?

Those are the important things. If you just look for a guilty you are wasting resolution time. This can be just an output of the error analysis and not your first target.

Finding someone to blame could help your ego but hardly will address the real problem.

Understanding where the error has been done

Errors are not all the same

Most important errors can be divided into specific categories related to the level.

You can have error at strategy level
You can have error at tactic level
You can have error at policy level
You can have error at execution level:
- Policies
- Process
- Procedures

Understanding where the error is mandatory to be able to address it and learn the lesson.

The problem is that, all errors have to deal with execution, because we measure the impact there, so it is a common mistake to stop the analysis at the execution level (where you can find your scapegoat to blame)

To find out what an error actually is and therefore what is its level somehow it is useful to do an approach similar to reverse engineering.

You should track back from the evidence of the error back to the real source.

At every piece of evidence you should take note of:

Is this actually an output related to the error?
What was the cause?
Is the cause related to something else?

The relationship can be to other outputs or to procedures and process that are related to the specific output.

Ones you collected all the evidence, of course the problem is to see what was the procedure or procedures involved.

Sometimes it can happen that procedures applied correctly have as an output an error, this is the simplest case. In this case you have to step back in your analysis to the process that is connected to the procedure.

Alas sometimes an error in the procedure can hide a problem in the process, so if a procedure gave as result a mistaken output it is another common mistake to stop the analysis at that level.

The correct approach should be something like:

• Why this output is wrong?

• What kind of cause has developed the error?

• Is this error an exception or it can be replicated in this or different scenarios?

If we are not able to make a model of the error we can hardly fix the specific procedure.

The things are more complicated when we have to deal with different procedures but it is basically the same.

When we have created a model that describe the error we can expand our analysis further and see if the problem is strictly related by the way we feed the procedures andor the whole process lack of control points.

Process and procedures are, of course, different things. But theoretically a sound process should be composed by different procedures that design its physical outputs in detail.

The process itself should contain the enforcement point and the control point, all described by specific procedures.

Sometimes an error is simply a son of a bad designed process. If there are lots of procedures, over complicated or simply overlapped the probability of an error rise up.

So, as an example, a big excel form to be filled manually is a bad idea from a risk error management point of view, because it makes easier to make mistakes.

If someone input wrong data on an excel spreadsheet the blame should be, mainly, on the excel form. If someone can make mistakes it means the excel is not the good data input tool.

Even if the wrong data input has been done intentionally the real point is that the spreadsheet is to blame, because the procedure itself did not implement good control point.

The tools are not a secondary aspect in an error analysis, and also user interfaces and control points.

Again looking for a guilty will not help you to learn anything.

Iterating this approach we should be able to regress to the point the error real root cause is, and so at this point we should be able to understand what really happened.

Strategy, tactics, policy, process and procedures

Going backward looking for root cause is a tedious and difficult job because the root cause can be related to several different processes apparently not connected one to another.

A human error, as an example, can be related to excess of stress, of lack of training, or bad tools and procedure design, a toxic company environment, a bad boss or a combination of all those things and more.

Sometimes the liaisons that cause the error are related to different levels, so some are at procedure level, some can be at processprocesses other can be even at tactics or strategy level.

And it is should be clear that in a company there are a lot of strategies in place: how to deal with personnel, how to deal with the market, how to deal with production and so on….

When strategy fails.

We just hope not to have errors at Strategy level; this is really a bad thing. It means we are doing it all wrong. In this case we should put in place a correction that requires questioning all the structure we have put in place. The problem with errors at strategy level is that at this level it means you don’t know where you want to go….

The good news is that at tactics, process and procedure level not all will be waste. But all the interaction should be revised carefully.

Tactics can fail too

This is more common, but nevertheless quite painful. Tactics without strategy is just a waste of time and resource, strategy without tactics is even worse, just mere words.

Tactics should put in place how we want to go there, but this can be wrong.

Wrong tactics are the usual problem in war, which makes people lose battles. And losing a battle can lead you to lose a war…

Luckily tactic can be revised from time to time and adjusted to the objective. But if we are not able to recognize an error at tactic level we can simply make all effort vanish.

Processes and procedures won’t help to cover a bad tactic issue, because they can’t address the root cause, may be mitigate the effect.

So if you want to win the market with a wrong channel approach (a classical tactic mistake) you can cover it for a while with price policies or sales policies but sooner or later you will pay the price in terms of higher expenditure and minor incomes.

Policy, processes and procedures.

When we are really lucky the error is related to the lower level, between policies, processes and procedures.

In this case, assuming we have designed a sound system, we can address the problem and the related externalities that the problem can cause.

It is mandatory, at this level, to be able to understand how the possible solution or mitigation can impact other process.

Correcting a problem we create thousands new

A common issue when analyzing an error to learn a lesson is that the solution can be worse that the primary cause.

This happen, usually, for 2 main reasons:

Not all the implication has been correctly analyzed
The problem is actually at a higher level.

This is common, as an example; when we try to fix a bug in software, and the fix create other unwanted problems.

It is not that the fix does not solve the issue; it is that the issue and the fix does not live in an isolated realm, but are interconnected with the rest of the structure.

Correcting a bug is a good way to understand the question we are trying to sort out.

A bug can be just a simple piece of code bad written, or due to an architectural error in the whole software.

But the underline lesson we should address is: if there has been a problem in code writing or architecture design why we made this mistake? How we can correct it’

The real solution therefore would not be to write a fix, this would be just addressing the contingency, and the real lesson should be how to make developer in condition to write better code.

Error handling is not learning from error

Another common mistake is thinking that running around fixing problems and managing errors would be a good way to learn a lesson.

Alas sometimes what you have to do to fix the problem is not what should do to avoid the problem from the beginning. Fixing a problem is just contingency and requires a different approach from learning the lesson.

If you run an emergency response team, as an example, those things are clear. There is a huge difference between what you should do in an ERT and how things should run in a normal way. And this goes through every aspect, form hierarchy to people management, to actions to be done.

Thinking to run normal operation as in Emergency is just foolish because ERT are made basically to provide containment not standard operation.

Conclusion?

Learning from mistakes is one of the most important things we can do to improve. The whole point is to understand what actually the mistake is, and how to avoid it in the future.