Typically when you are resolving issues you apply a short term solution that resolve the one instance that is occurring, similar to putting a band aid on the issue. This resolves the current issue but it does not stop it from occurring again. In 2004 I was working within a team as a system engineer and was implementing an oracle solution on a Linux server. It was found that the servers performance degraded significantly after a day or two, so to resolve the issue I volunteered to come into work each day at 6am and restart the server.
This was like putting a band aid on the issue. Each day I had a little workaround that stopped the problem from revealing itself throughout the work day. To the user there was no issue, however, there was an underlining cause of this problem that was not resolved and was causing addition work that I was required to do.
In IT we have so many opportunities for improvements, so many workarounds, so many procedures that the help desk is trained in to resolve common problems. What lean provides is a methodology for getting to the root cause of the issue, not just covering it up or resolving the symptoms. IT departments have two key roles; that of implementing projects and operations. The operations team are normally there keeping the lights on, limiting change and have a large collection of workarounds for common issues that occur. Wouldn’t it be great if the operations team worked towards the root cause of issues and stopped the issues occurring once and for all? The lean methodology is highly respectful of people in utilising their thinking power to resolve issues once for all, not just forcing them to follow workarounds. Two of Lean root cause analysis tools are asking why 5 times and the fishbone diagram. I will discuss these further in a later post.