Is improvement old-fashioned? Is process going out of style? It would seem that, according to the Google Ngram search on Process Improvement, it started being discussed in the mid-1980s and peaked around the year 2000, and has now started declining.
Process is largely the transformation of one thing into another, through a series of steps. It is often confused with documentation and bureaucracy and regimentation, but that is not the point. Process Improvement is about making that transformation more efficient and/or effective. It is hard to believe that we are no longer interested in improving efficiency in this new millennium.
Process improvement continues to work. It is not about creating bureaucracy and loads of documentation, quite the contrary: it is about reducing the difficulties to react to changing conditions. One of the words, we use in the process improvement world is “Maturity”. Maturity is the ability to use your knowledge of your own skills, strengths and abilities to react rapidly. It means making sure that you are not continuously running into the same problem every time, but trusting in your colleagues (and yourself) to resolve common issues rapidly and efficiently. One thing that anyone with maturity will recommend is that you should not rely on a single solution for all your problems. The fashion currently tends to promote Agile and DevOps solutions – neither of these is always the best solution; neither is CMMI.
Process Improvement practice in general – and models like CMMI in particular – focus on the understanding of what you should be doing, without prescribing how to do things. CMMI tends to talk about documentation, but it does not mean a lot of books and paperwork, it means communication through space and time: documentation means that I can share my experience with colleagues next door, and I can look back in six months’ time to find out why I was successful or not. Agile and DevOps promote communication, they don’t mean just chatting with people and forgetting immediately, they mean capturing lessons, requirements, changes, progress, etc. in such a way that it can be reviewed and understood afterwards – in other words they are promoting documentation.
So, process improvement is falling out of fashion because of terminology? Surely, it still makes sense to understand the process, what you should be doing, why it is important, what are the consequences of doing it or not. Surely, that is at least as important as a methodology which gives the way to do things without explaining why, or what are the benefits of the approach?
When did anyone start considering that improvement was a bad thing – unless they fear being questioned about the only solution they know?