Organizations both big and small follow processes for many different reasons. Why? To get things done consistently, sure. To ensure quality and avoid defects, yep. To ensure compliance with standards or legal requirements, of course. It has been my experience that once established, a process adopted by an organization tends to be hard to change, and processes tend to grow and multiply, kind of like weeds. It seems like most of this growth is reactionary: processes are added to, modified, stacked, and extended to cover new issues and expectations, and to absorb blame when something goes wrong. It gets even more fun when you have large organizations with full time employees whose job it is to create, update, extend, and dictate processes. Think about government, medical, or the last time you dealt with a telecom.
When Process Starts Working Against Itself
During my days creating a digital representation of the earth (which sounds cooler than creating digital maps) there were processes for breaking down, categorizing, and coding into a database everything that appears on a map of the earth. That is a whole lot of attributes, and when you consider adding all the attributes it takes to create a representation of all the road networks on earth, which have upwards of a thousand different types of attributes, you can guess how complicated that process needs to be. It starts out with a complicated process, then there are processes for QA, QQ, and QC (Quality Assurance, Quality of Quality, and Quality Control). One would think that might be enough process, but over the years even more got layered on top. This added complexity delayed map updates so much that the company actually developed a program called "Fast Map," which gave customers access to the data before all the processes were completed. So a process was invented to get around the processes that were in place, all to ship data faster. "Houston, we may have a problem."
Why Processes Get Bloated
So why do processes become bloated, cumbersome, time consuming, and painful? My experience has been that it is typically in reaction to some type of issue or exception. Nobody adds a process because they're feeling proactive. Something breaks, and suddenly there's an addition (or many additions) to an already long process. Hey, this crazy thing happened, we did a root cause analysis and this thing was not covered in the process, so we need to add to the process to prevent it from ever happening again. Sometimes this is completely valid, other times it is just papering over some other underlying issue, like lack of training, lack of automation, lack of testing, or just plain old stupidity. Multiply that by years (sometimes even decades) of this happening, the process being added to and never pruned, and you start to get why in some organizations it takes months to make a change, stand up new software or operations, or adjust anything.
I too have created bloated processes. Years ago, we had a software bug get deployed that messed up thousands of images during a conversion process. These got shipped to customers. The issue was not identified for months, and then it triggered an emergency reshipment. The short term response was to change the process to manually QA every single change to over 10,000 images until automated scripts could be developed to check any new image change committed to the repository. Once the changes were made and tested, we actually had a hard time getting the process changed back to not having all the images reviewed before shipment. Because this issue happened once, the thought was that even if the root cause had been identified and tests had been added, it "could" happen again, so the process was needed. Luckily, we were able to stop that insanity simply by showing how much money would be saved.
How To Keep Process In Check
There is a line to be walked between too much and too little process. Here are some things that I think about when I think about processes:
- Every process should have an owner and an expiration or review date, or it's immortal by default. If it is not owned and reviewed, it has the potential to grow out of control, become so institutionalized you don't know why you do it, or just rot.
- Ask what a process is protecting against, and if you can't name the failures it prevents, kill it.
- One exception doesn't need a new rule. Sometimes an exception is just an exception.
- Fewer, sharper rules beat comprehensive ones nobody reads. Read KISS.
- Complexity costs time and money, which is one of the reasons startups with little process can move quickly. Processes should be considered in the light of time, cost, and efficiency.
You weed your garden, you clean the rooms where you live, you try to optimize your time. Somebody has to actually pull the weeds, or pretty soon that's all the garden is. Like it or not, organizational and software processes could use that kind of attention.
