Process versus flexibility

I heard an interesting statement (just minutes ago) that really struck a chord with me. agreed, we need to have a balance between proceess and flexibility which both resonated with me, but also sent a shiver up (and down) my spine. A common thread I see is that folks who like "process" tend to be "inflexible" and people who espouse "flexibility" do so at the expense of "good process". I disagree violently and think this is a false dichotomy. At the end of the day, "a crappy process" or "an ad hoc process" both still a "process", and having either of those processes is no more or less flexible than having a vigorous and dynamic process that supports what you're business objectives.

The problem as I see it is that "process" has gotten a bad rap because many egghead know-nothing consultants have sold horribly convoluted and untenable processes to folks and when said customers see their effectiveness crash, they blame the "process". Having lived through this, I've seen many ad-hoc and not well though out processes be VERY effective and watched (multiple times) well meaning, but misguided academic "one size fit's all" processes wreak havoc on a system that, instead of being improved, was utterly destroyed by a new...but ineffective...process.

My stance is this: If your business model needs flexibility, you process should support flexibility in places that it makes sense...but it should discourage flexibility in places where it's working against your goals. In the "process" camp, many people fall victim to the idea that "I've designed the 'ultimate' process...if your business needs don't fit into it, you're a stupid head". On the flip side, the "process is evil" camp, there's the notion that "process is for morons, I have smart people, I can just change things at a moment's notice and they'll just do whatever they think is right and magically everything will work out". Obviously both of these are wrong (put this way), but at the end of the day, not using process oriented thinking will lead to conflict.

Listen, an "ad-hoc, do what you want" process is still a process. I would contend that an entire company set up where everybody just does what they feel like doing at that moment regardless of business objectives...will fail quickly...unless coincidentally everyone's goals happen to be aligned and they have perfect knowledge of what each and every other person is doing. Yet again on the flip-side...process for process sake is just dumb and generally only rewards management consultants and people who really want to move papers from point A to point B.

In conclusion, the important thing to remember is that your process should support things you want to happen, and discourage things you don't want to happen. If the risk/reward within the process is equal or upside down, you will spend time fighting the process instead of letting it support your objectives. Put another way, the goal is to make the process YOUR tool, instead of being just a tool abiding by the process.