In the current Information Week, Art Wittmann explains that process is to slay the Jabberwock:
One challenge for those in IT organizations is not to become so enamored of your own process that you lose sight of serving the business first and foremost. I saw this happen early on in my IT career after a boss went to see Edwards Deming talk about Total Quality Management.
….
Of course, it didn’t work that way. Certain things lent themselves to the TQM process and some didn’t. In particular, there are always those little exceptions, the small jobs that IT teams need to do without running them through whatever process you’ve chosen, because if you did run them through your process, you’d either miss the window of useful opportunity or you’d turn that small job into a big, expensive one.
We longed for some sort of 80/20 rule. We would happily use the TQM ritual for most of what we did, if only my boss would let us quickly deal with the innovation-oriented 20% of tasks that didn’t fit that model. It never happened, and rather than getting behind his TQM philosophy, we and business side peers rebelled, to the point where my boss lost his job.
The problem was that we were being asked to serve the process rather than serve our constituents in the business. Today, I see the same thing happening, often in organizations that are heavily committed to ITIL or some other definitional methodology.
Oh, I recognize that mindset. I saw it aplenty after sitting through process meetings where we discovered previously unknown gems of process, such as When the designers finish the design, they send it to QA, and QA looks it over before it goes to the dev team! Gems of process that hide in plain sight, but which we had to glean and polish in hours of process meetings.
Then, when we finalized the document and everyone signed in blood, the customer facing people, LOB in Wittmann’s vernacular, found that 20% in 100% of the cases that follow. “The client needs this now!” “We’re behind, so we just gave it to the development team with the misspelling of the client products on the buttons and everything, to dev so they could put something quick and dirty up,” et cetera and et cetera.
Then the personnel would switch (let’s just say the turnover at an interactive agency isn’t as bad as a Burger King, but probably worse than a Wendy’s), and we’d be off to make more flowcharts of proper process to ignore.
As I’ve said before, a proper process takes into account that the weasels in your organization are going to try to subvert or ignore the process whenever possible and to create alternative paths for those cases. If the client returns items x days/hours late or the x days/hours/minutes before or after the end of the milestone/stage, shorten the process by this. But only in those cases.
Otherwise your LOB customer-loving, over-promising people will continue to argue that the current effort should not be constrained by process just this once.