Process - The real problem?

Is process he real problem we think it is, or are we making a mountain out of a mole hill?.  If you work in the technology field then I'm sure you've run into the process beast at some point in your career.  It may have been that problems arose due to a lack of process, the wrong process or too much process; but at some point we've all faced it.  The real issue though isn't the problems process may create, but how we handle these problems and, more importantly, how we approach process itself.  Do we take the lazy way out and blame all our woes on the process, therefore leaving us unaccountable, or do we face it head on, acknowledge the issue and take the necessary action to fix it.  

When process fights - fight back

Just like a developer tackling a bug we shouldn't take the lazy way out.  Pointing a finger at process only prolongs the issue.  Instead we should face it head on.  To do so we need to don our problem- solving cap and determine why process has caused our issue.  In some cases it could mean a flat out removal of a specific process - especially if it's blocking and useless; for example, all changes must be approved by Joe even though Joe has no idea what he's approving.  In other cases, it could be that the process has created a time draining workflow and just requires a simple adjustment to be more effective.  There are also many times when the lack of a defined process can wreak havoc -  in these cases some process may be better than none; just remember that process should be treated like code and iterated upon as it is most likely never going to be perfect right out of the gate.  Once we know the bug in our process we should fix it immediately, testing it on our problem and other use cases to prove we've corrected it appropriately.  Using a process untested is just like pushing a bug fix into production without QA; you might think it fixes the problem, but when released into the wild it causes issues with other use cases.

Process is iterative

If we treat process as we treat code then we know it won't be perfect and instead will be in need of constant improvement.  If we accept this statement as fact then we set ourselves up to be flexible and agile, thereby reducing either the issues caused by process and/or the turn-around time to resolving a process related issue.  One might even consider process a "project," tracking issues against it just as you would a widget you were building.  If one takes this approach then we'd see the process achieve improvement as it matured vs remaining stale and having users deal with a broken process forever.  Another approach would be to review all processes periodically to determine if they are still valid and/or if there are improvements that can be made.  It doesn't matter which approach you take, so long as you remember that no process is perfect and therefore needs iteration to be effective.

In conclusion I'd say that process is rarely "The real problem", but rather our approach to it.