Process-improvement – lesser is better

I was just thinking of something, and thought I’d ask people in general.

If process-improvement is supposed to optimize the methodology for better/more output, then why is the default thinking around it ‘additive’? As in, when organizations think of process-improvement, they generally think of things to add to the process – be it documentation, an extra step/approval/review of something, some kind of audit, quality assurance, and so on.

Shouldn’t the default be – what can we remove from this process, and still produce better quality stuff, and more of it?

4 thoughts on “Process-improvement – lesser is better

  1. You are rigth. Business process reengineering will probably eliminate redundant tasks, consolidate different ones and get rid of some control tasks (this is possible if you take quality into account in the design processes).

  2. I think the problem lies in the difference in the volume of effectiveness (doing the right thing) problems that we try to address with process and efficiency (doing the thing right) problems, which we see less often and/or don’t address.

    There are many types of effectiveness problems that, when analyzed, can lead to more process in the guise of improvements. This bug slipped through the cracks, the users hated our screen design, the support department was unimpressed by the supportability of our product, the management stakeholders are unhappy with the *lack of* transparency of our project metrics, the requirements for this SOA interface were misunderstood, etc. Many of these types of problems are most easily (note that I didn’t say effectively) addressed by something more that could be done to eliminate the problem in the first place. Hence more steps get introduced to the process.

    The types of problems that are addressed by *less* process are related to efficiency. Our turnaround time on bug-fixes is too long, our build takes too long, we spend too much time triaging issues and not enough time fixing them.

    I hypothesize that we either see more effectiveness than efficiency issues in software development, or we’re just more tuned to fixing them.

    One approach would be to use a more root-cause approach to the analysis of problems. I think that in some cases, we’re simply not peeling the onion enough to get to the root cause (the five why’s), and to identify an effective solution instead of the easy solution. By diggin deeper, we may ultimately gain improvements that refine process rather than pile on to it.

    An interesting approach to balancing the ledger (to ensure we’re not just piling on more process) would be to do as we do in scrum iterations. In scrum, if you want to add scope to a sprint, you have to take some other scope away. If we did that with process, or at least raised the question of what to eliminate to make room for additive process, we might yield leaner processes.

  3. I completely agree.

    Optimizing a process (itself) at the expense of the end-goal is definitely a case of optimizing the wrong thing.

    Kind of meta-circular, if you think of it. Optimizing the steps of a process could be a case of incorrect local optimization when viewed in context of the overall throughput of the system.

    Anyhoo. My point was just that the *default* should be to make a process leaner, as opposed to adding to it.

  4. Perhaps the Open-Closed principle applies to process as well as software. That is, there is a higher risk of breaking things if you change them, whereas if you add something then the risk is low.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s