Thursday, July 23, 2009

Good and bad about process improvements

Improvement is always something positive as it makes the processes better. However, process is a fine mechanism that needs delicate treatment. Many times the ideas that were deemed a quantum leap ended up with just slight changes in the quality of output. The reason why the reality does not fulfill our expectations is in relative complexity of the processes and the number of factors that influence the outcome.

There is also a problem with preciseness, with which one determines the root cause of a problem to be eliminated. For example, we have a big number of small UI defects and decide that additional check by developers will dramatically decrease the number of such issues escaping coding phase. However, we may be wrong about the actual root cause. It may be not due to erroneous development but rather due to obscure requirements. So, the actions we defined may not bring the desired results.

Most of ideas on process improvement come from the performers. In order to get the feedback you need to learn how to listen what people say. Encourage constructive criticism on the processes. Never give up the feeling of resistance to the critics even though what is being criticized is your precious creation.

Metrics is another big-big source of clues on improvements. They say measuring without a clear idea of the purpose is not a good idea. I would argue this statement. I have a very positive experience of collecting everything possible I could collect about the project with successful usage of that information in decision making and defining improvement program. So, if it takes just a bit of time do not hesitate to jog numbers down. Who knows what application you may find for it tomorrow? Everybody knows that having historical data is a key to every performance and quality tracking program. The sooner you start collecting your data, the better. But please do not pay too much of your time to it. Else you will not be able to do your job!

Improvements should be carefully estimated and prioritized. All the more, improvements shall be carefully planned. And here you have the most difficult problem - resources. This is normal that all company's resources are busy on tasks directly contributing to revenue. And it may be difficult to detract your colleagues for working on process improvements. In my experience, most of good improvements get killed by this limitation. Here you have two options: procure resources by communicating goals and ROI to top-management; find enthusiasts who will do this in their spare time. The latter is not likely to happen so do not rely on it too much. I knew a manager who always appealed to enthusiasm, whereas everyone was reading "overtime" between his words. I always wondered why did hi not call things their real names? %)

Once you have a plan mind to define measures that will tell you whether you actually changed anything, and whether the changes were for good. Metrics are vital in every process improvement program. Else you will definitely persuade yourself that what you did was good, no matter of the real end result :)

Good luck in your improvements!

4 comments:

  1. There is no process in my office at present. But now the management wants to define a process. In my previous job we followed Agile and scrum as tool. So I want to establish scrum. Can you suggest me which metrics are the vital for scrum and a reference for those metrics?

    ReplyDelete
  2. Hi!

    Asking which metric fits certain methodology is not quite correct. The best way to establish metrics is to grow it from your needs. In Scrum they do post-mortem reviews where they find out root causes of why things went wrong and form the idea how they could do better in the future. Those ideas can be transformed into action plans. In result of execution of those actions you should see the changes. Metrics are needed to measure the change, to tell you whether you have improved and did it to the extent that you expected.

    For example, you may find out that it took a lot of resources to fix defects related to backend components. You know that there were 50 issues reported against backend. So, you decided to focus on unit testing of backend next release. Next release is about 0.5 of the previous in size, so you would expect 25 issues from backend if you have changed nothing. But you are expecting improvements to limit the number of issues to at least 5. Measuring the number of backend issues after the process you will find out whether the changes you ave made hit on target.

    Every improvement that you plan should have a measure that will tell you whether you are where you wated to be after the fact.

    Hope this helps! Feel free to ask more questions.

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Good article Vladimir. I completely agree, without measurment we cannot gauge if it is a process improvement or an overhead to the company

    ReplyDelete