Process Improvement

It’s interesting to see how different people react to the idea of process improvement. Most people fall into one of two camps - I’ll term these the Conservatives and the Radicals.

Conservatives don’t see any need for change at all: “That’s just the way we do things around here, we get the job done, and I’ve got work to do anyway.” They put no effort into process improvement, and therefore realise no improvements. They never make things worse - but they never make them better either.

Radicals want to rip everything out and start over: “We could be so much more productive and competitive, if we’d just take a little time and make some changes to the way we work. Of course, as we work on our defect workflow, we should revise our requirements strategy in order to integrate, and that means looking at our project management methodology…”

Making a radical change takes a massive effort, with lots of meetings and plenty of (often heated) debates. Much of this effort goes into attempts to fully capture all the appropriate nuances and every special case, sometimes trying to develop a fully qualified process where every step is defined and every exception known in advance. The end result can be massive quantities of documentation that make even the simplest process seem daunting and complex.

There is a better way, of course - to take a middle path, an Organic approach.

Firstly, and importantly, keep the process you currently have, retain everything that is providing you with value. Don’t throw away what works.

Identify an area of “process pain”, an aspect of your process that is causing you difficulty. Perhaps your build process is clunky, the classic “simple 47 point checklist”, or maybe you have no build process at all. Source control, testing, project or requirements management, documentation standards, or something completely different.

Once you’ve identified an area to improve, select a good improvement to make, one that you can achieve without requiring excessive effort. Try out the change for a reasonable time and then evaluate the change. If the change proves to be an improvement, keep it. If not, revert back to the way you used to do it and try something else.