Take this Process and Shove It!

I've often been struck by the way various companies and individuals feel about business processes. On the one hand, without process you can have chaos, a lack of quality, and create a ton of work and trouble for everyone in the organization. On the other hand, process often feels like mountains of paperwork, slowing everything down and making some things impossible to get done. Some individuals are comfortable with (and comforted by) processes. Others bristle against their constraints.

Often these issues are discussed in terms of whether a company has too much or too little process. Like Goldilocks, we're looking for the amount of process that is "just right." But I'd argue that "too much or too little" isn't the most important or productive question to ask.

We should be asking "What is this process for? When and how could we circumvent this process?"

Let's start by asking why we have processes in the first place. The Google result provides a great starting point: 

proc·ess
1. a series of actions or steps taken in order to achieve a particular end.

The key bit of this is "to achieve a particular end." In other words, a process exists to help organizations reliably meet a certain goal. Too often, though, the goals of the process are not clearly documented or understood by the participants. So let's start by ensuring that everyone understands what the goal of every process is. 

How does this help? Let's say you're trying to get something done...perhaps get a project completed quickly with an outside vendor that hasn't previously worked for your company. There's a process for qualifying vendors that typically takes a few weeks. Unfortunately the holidays are approaching and the project really, really needs to get done before then...let’s imagine it directly impacts revenue. The process is in place to protect the company from a variety of bad outcomes related to vendors -- anything from poor performance, to shady business practices, to ensuring they comply with applicable laws.

The procurement team wants to run their process, of course. But they shouldn't want to run their process. They should want to achieve the goals that the process is designed to achieve. And, of course, both the project team and the procurement team probably want to increase the company's revenue. So they both share that goal. And the project team wants to protect the company from bad outcomes too. When you reframe around goals and how to meet them, the conversation can change. 

Of course the teams still may not agree. Likely the procurement team places more weight on the risks and the project team puts more weight on the revenue. It is then important to have a way to resolve the disagreement. Who can give us permission to circumvent the process? Who can decide on the risks versus benefits? If that is clear, even in the case of the disagreement, we can get an answer quickly. The benefits of process without the headwinds of bureaucracy. At LinkedIn we have a process for this that you can read about in Mike Gamson's excellent post.

In short, the process is there to help your organization meet certain goals. If it isn't doing that then you should throw away the process, not the goal!