Learning from Mistakes

I was recently reminded about learning from mistakes when I was watching my son draw a picture of a car. As he was contouring the shape for the hood he stopped abruptly and had a distinctly irritated scowl on his face. I recognized this as the beginnings of a drawing being crumpled and chucked into the bin. I asked him what was wrong, and he said that the roof was too long and the hood was too short. I reassured him that it looked fine to me, but despite that he made some modifications of his own and turned it into a monster truck.

The same principle can be applied when we are reviewing incidents, problems, or changes.

The reason we have these reviews is to identify what went well or not so well in the first place. Whether it is to review the latest major incident or a component of a failed change, we need to know what happened and how to prevent it from happening again.

In my opinion, to get the most out of these meetings you need to set a tone that this is a place to learn and make improvements, not to point fingers. Through my own experience and via feedback from others, this is not always the case. The challenge is to get people in a state where they can share the details freely rather than having them concerned that sharing could inadvertently put them in the ‘hot seat.’ When the collaborative spirit is diminished, the ability to improve is reduced.

In a climate where we are able to have a high level of transparency, we are able to gather factual details from several stakeholders on what really happened. This allows you to get a better picture of what really happened. In some cases this might have been the result of a mistake. The important takeaway is not that a mistake was made, but instead that we learned from a mistake and made improvements to overall support of a service. While people in the meeting may have learned something, we also need to make sure that this information is shared with a larger audience to educate the rest of the team on what happened.

Aside from transparency, make sure that these reviews are scheduled soon after the issue has occurred. Everyone is busy, but when we start pushing out the meeting time or have those who can’t make it, you will find that details may get lost in the shuffle.

Make this review a high-priority activity rather than a side effect. Think of it in these terms: While this may not fit your schedule now, repeating this issue will eat into not only your schedule but also the perception of how you provide service later on.

Keep the meeting simple. You should review the timeline of the issue, including details such as:

  • What happened and at what times
  • What decisions were made and why
  • Any assumptions that were made
  • Things that were tried and did not work
  • Fixes which were discussed but not tried

In the end, as you wrap the meeting up, quickly review what was discussed, including the impact to users, preventative activities, and lessons learned. If there are action items, ensure that they have a deadline and that this is followed through with the same priority as the meeting itself.

Remember that the issue has already happened; we just need to identify what to correct. Learn from it and turn this car into a truck.

Looking for guidance in your ITSM Journey? Contact us today!

Interested in ITIL4 Foundation Training? Check out our upcoming courses