One of the most universal findings we encounter on our research travels is that, contrary to what we may hear from elsewhere (IT vendors, subject evangelists), IT professionals generally want to deal with fewer processes, not more. Or to be precise, they want ‘just enough’ process. This idea is firmly rooted in practicality and …
Can't see the forrest for trees ...
"So where does the middle ground lie?"
Stop fscking over analyzing, and let (real) IT staff get on with our job. We can, and do, actually provide you with email and pointy-clicky-webby stuff, despite all the road-blocks that clueless management tend to throw underfoot ...
 "real" IT staff being the educated folks in the trenches, who are doing all the little things that are allowing you to read this ... and your email.
 "clueless" from a technical perspective ... IT is new territory, quite different from traditional management that grew out of the feudal system.
processes produce consistency
That can be consistently good, or consistently bad. it all depends on what practices the process was modeled on. It also defines the lowest acceptable quality of output from that process. Guess what happens next? Yup, the lowest acceptable quality becomes the norm - the target. Nothing more than that is expected, or delivered as over-achieving takes longer than necessary and costs more. all for no added benefit. Frequently, a process will define the maximum time to respond - once again, that becomes the target figure too and all deliverables will tend to be delivered at or near to the target time, rather than earlier, even if they have been produced in a timely fashion (although that wouldn't happen, as there's no incentive to produce anything earlier than the deadline).
So if a process says the maximum time allowed to respond to a service call is 6 hours - then in 5 and a half hours, you can expect a call. If the process defines a response as merely an acknowledgment, then that's what you'll get: not a fix, just an email to say "^Thank you for your submission. We will get around to doing some real work in due course."
Where does all this leave the motivated, conscientious and enthusiastic workers who WANT to deliver high quality solutions (or products) in a fast and effective manner. Well, they can if they want to, buy there's no incentive or recognition for doing so - so they become demotivated, stale and cynical jobsworths who will play the system and do the minimum amount necessary to just scrape past the quality metrics. Or else they'll leave and go to forward-looking companies where their initiative and energy is harnessed, rather than dissipated, ignored or even criticised for making the other team members look bad.
Processes CAN help to produce good enough results, but all too often they don't reward the best people, crush initiative and cannot differentiate the high quality staff you would wish to keep, from the indolent types who will hide behind non-compliance in their inputs as excuses to not do any work. Essentially a process is a procedure and a procedure (as we know, since we're IT people here) is a subroutine and a subroutine is part of a program. Just look at ITIL - a software specification, if ever there was one. Programs are for computers to execute - not people. If your job is sufficiently repetitive and deskilled that it can be described in terms a computer can understand, then that's what should be doing it, not you:. Unless of course, you're happy being a drone and don't mind being laid off just as soon as it becomes cheaper for a small beige box to be wheeled in, and for you to be wheeled out.
- Vid Antarctic ice THICKER than first feared – penguin-bot boffins
- Hi-torque tank engines: EXTREME car hacking with The Register
- Review What's MISSING on Amazon Fire Phone... and why it WON'T set the world alight
- Antique Code Show World of Warcraft then and now: From Orcs and Humans to Warlords of Draenor
- Product round-up Trousers down for six of the best affordable Androids