Brunel University's Business Class: How to turn a mistake into a positive event

National football team managers always lament the time they get with players after games, before they return to their clubs, to go through what went well and what went wrong. This month Brunel's Professor Robert Macredie and Dr Mark Lycett say the situation is much the same in most IT departments after projects end...

History may repeat itself but it's our duty to try to learn from mistakes. In a recent survey carried out by researchers here at Brunel, only 2 per cent of respondents – all senior IT managers – stated they had a formal process of feeding back lessons learnt from project implementation. This is a shocking admission, in no way excused by the short-sighted reason of 'we're too busy'.

I'm sure the brutal truth in many companies' IT departments is that mistakes are repeated, time after time. It goes without saying that this must be costing businesses money and since time is money, the less time we have, the more money we waste. Perhaps by identifying the reasons why we rarely learn from our mistakes we'll be able to save money, use our time wisely and effectively buck this trend.

First, it's important to explain what a mistake is. A mistake is a lesson learnt but not shared. As soon as a mistake is shared, explained and understood, then it becomes a lesson learnt and a mistake is turned into a positive event. It's this openness – sharing of lessons learnt - that is so rarely seen, in any department, not just the IT division.

A question of circumstance If blame is to be apportioned, much of it must lie in circumstance. In a typical software development process, project teams are gathered together at random, according to who is free. The team works together for the duration of the project then quickly disbands at the end to start work on other projects – and so the cycle continues.

Often, whether a lesson is learnt will depend on the individual qualities of the team member. If they are confident, well respected and vocal, knowledge may be passed on. If they have little standing within the new team, mistakes are likely to be repeated. Even if there is some formal reflection period at the end, feedback is seldom formalised into a working practice.

What price learning? This leads to the next issue - cost. Feedback may not be formalised into procedure. The reason for this usually boils down to money. Discussion of mistakes is rarely seen as a 'revenue generating' task. Faced with choosing between a thorough review of lessons learnt or moving team members onto the next project, the latter is the obvious choice.

What's more, if the team were to carry out formalised reviews, devising a procedure to feed the lessons learnt back into working practices would undoubtedly take time - and so money. Since it's not perceived as a cash generator but as a cost centre (whilst the team could be more 'gainfully employed' developing software), this best practice procedure rarely happens.

Repeating the same mistakes It would be interesting to gauge how often mistakes are repeated. I'm sure everyone has plenty of anecdotal evidence of this. The example of one large company – which in many areas has an enviable record of best practice - springs to mind immediately. Software components were being developed by different teams, both in parallel and consecutively. This meant that there was plenty of time for reflection, yet since there was no knowledge share between teams, this did not happen.

The outcome was that each component had the similar flaws. Every single component required rework – at considerable cost to the company. How much cheaper would a little reflection have been? The stark truth is that, while it costs money to transfer knowledge, ignorance costs more.

Breaking through the blame culture The final reason that mistakes are repeated centres around an organisation's culture. A child's reaction when they've done something wrong is to cover it up, pretend it didn't happen – or worse still, blame it on someone else! Translated into a business environment, this is turned into a blame culture, creating an environment in which we're trying to be seen as perfect.

Strive as we might, this is obviously not true. Since nobody's perfect, it would be much more refreshing to reward people for owning up to errors, turning a negative mistake into a positive lesson.

One of the beauties of the written word is that it has an amazing capacity to seem simple. All of the points made above are basic common sense, which (we hope) will have many readers nodding in agreement or smiling ruefully in recognition. The hard part is to turn around years of working policies, procedures and culture to put 'learning' into practice. It may be a tough task but the long-term dividends will be considerable: you'll be able to say that the IT department you work in never makes mistakes.

Professor Robert Macredie and Dr Mark Lycett are leaders of 'Fluid Business', a groundbreaking research project within the Department of Information Systems and Computing at Brunel University. They will be writing for silicon.com on issues of technology and business over the coming months and can be contacted by emailing FluidBusinessTeam@fusepr.com. Or email us with your opinions at editorial@silicon.com.