Learning from Mistakes

Learning from mistakes is crucial to your success on projects.

One of the axe-sharpening activities for which there is seldom time is the activity concerned with understanding why mistakes were made and crushing them out of the process so that they do not occur again. One of the reasons why these activities are not usually allowed is that the time they take is not usually in the schedule and because many of the benefits are for future projects.

You can cure this in several ways. In the beginning do not attempt too much. Preventing defects, like politics is the art of the possible. Prevention of Defect meetings should happen, during projects, only when sub-systems are delivered into test, not when individual programmes are delivered. They should only analyse higher category defects. At one organisation, they had nine categories of defects of which they analysed only the top five categories.

The Lesson Learning meetings should last only an hour. There are two purposes for the meetings. The first is to ensure that the person who created the defects understands why they happened. If they take time out to understand why they created the defects they are less likely to create them again. This activity happens in other professions.

Football Clubs

At football clubs they use video evidence on a Monday morning to analyse the problems that occurred in the match at the weekend. The players are then able to analyse and visualise what they should have done. It breeds good habits. When Liverpool were the top team in the country, whenever a player was transferred from them to another club, the manager of the new club would always try to find out from the player what the Liverpool secret was.

But there was no secret. As Bill Shankly said, they hired the best people and did the simple things. They didn’t do things like pass the ball across their own area. They had cut out all the mistakes which had caused them problems in the past. This was good people with good processes.

Mistake Analysis

The second purpose is to allow the analysis of these mistakes so that the process can be changed to prevent the mistakes happening again. In the past I have found that many of these problems occur because of misunderstandings at various stages. Very often this analysis leads to elements of Rapid Application Development (RAD), especially Joint Application Development (JAD) being taken into the process and the use of developers rather than analysts, designers and programmers. The fewer handovers, the fewer misunderstandings there are.

Standard Practice

Fortune magazine once analysed the software practices of the top 500 companies in the USA. They found that there were four main practices which separated the best performing software departments from the worst. These were:-

o  Standardisation – of platforms, methods, models etc.

o  Joint Application Development (JAD)

o  Timeboxing

o  Prototyping

You may short circuit many of your defects by implementing these best practices.

You should analyse your mistakes so that you are constantly learning from mistakes and getting better and more productive as an organisation.