Opinion: Let up on process, but don't abandon it

IT Departments need to loosen up, but still retain control, says Bob Brown

Next-generation IT leaders take heed: Everyone hates process. The evidence is all around you. From the helpdesk to the corner office, employees do their best to subvert even the best-intentioned processes whenever they seem inconvenient. The solution isn't a process-free IT organisation — that way lies chaos. It's knowing how to bypass your processes when they don't fit the situation, yet not lose control. After all, next-generation IT should be focused on creating value in collaboration with the rest of the business, a mandate that requires both a firm hand and flexibility. IT practices vs IT processes

Small IT shops rely more on practices than processes, and as I've argued before, organising some key functions into "practices" is a key component of next-generation IT, even for the biggest IT organisations. "Process," you'll recall, refers to a way of organising work that relies on a well-defined sequence of steps that lead to repeatable, predictable results. Sounds good, doesn't it? Sadly, the more organisations rely on well-defined processes, the more rigid, bureaucratic, and overly formal they feel, both to the employees who staff them and to everyone who works with them. They increase overhead, too (aka the cost of keeping the lights on). "Practices," in contrast, rely much more on individual initiative and creativity. As a result, they feel less formal and more fun. They also, as it happens, increase adaptability and reduce fixed costs. This doesn't mean practices are superior to processes. It means most people, most of the time, like them better. One look at the traditional help desk shows you all you need to know. Learning from the helpdesk

As IT organisations grow, it's something of a tradition that they do everything they can to discourage users from calling their favorite IT analyst when they encounter a tech problem. First they establish a formal "service desk," (the official, ITIL-approved synonym for "helpdesk") equipped with incident tracking software to make sure no problem falls into the cracks. Then they define a standard incident management process for analysts to follow, down to the sequence of troubleshooting steps, including the invariable first one: insisting that callers reboot their computers. When the knowledge base of troubleshooting procedures is exhausted, helpdesk analysts escalate the incident to the proper queue of theoretically interchangeable problem-solvers. Meanwhile, "favourite analysts" - those who have established reputations for solving problems quickly - are instructed to refuse any and all calls for assistance. They may only work on incidents the helpdesk escalates to them. When an IT organization institutes this sort of incident-management process, there's only one certainty: Everyone will hate it, for the same reasons everyone hates all business processes. It traps everyone into a one-size-fits-no-one way of dealing with situations, and because the help desk is the part of IT that everyone has the most contact with, all of IT's reputation suffers. Of course, as IT continues to grow, both in size and complexity, everyone would end up hating the favourite-analyst alternative to the rigid helpdesk even more. They'd describe IT as unreliable, reactive, and out of control. Again, it wouldn't be just the helpdesk. It would be all of IT because the helpdesk is the part of the IT iceberg that shows above the water. It's Hobson's choice all over again. When it comes to choosing between practices and processes, you're dinged if you do and you're dinged if you don't. Lucky for you, I have the solution. You are your worst enemy

One of my early clients, a very talented CIO, brought me in to assess his organisation's progress a few years after I'd first worked with him to develop a turnaround plan for his department. After interviewing everyone in IT and a sampling of business executives, managers, and staff-level employees, it was time for an uncomfortable conversation. "For the most part, everyone in IT seems to have adapted to your new incident management process, and they want to make it work," I told him. "For the most part?" he asked. "Yes. You do have one person in IT who sometimes sabotages everyone else's efforts to make it work." "Who is that?" he asked, falling into the trap. "You." It turned out that my friend and client saw his role as helping frustrated users - especially frustrated executives - bypass the new process when it wasn't convenient for them to follow the guidelines. It took little additional conversation to persuade him that his proper role wasn't to help anyone bypass the new process. It was to help them work the process. One problem: There was no way to work the process. It was, in fact, rigid - so was born the "process-bypass process." A process-bypass process is as the name implies: a defined, allowed way to skip one or more steps in a process, or to invent new ones for one-time use while still operating within the overall process umbrella. Process-bypass processes aren't just for incident management. The specifics vary with the process and with the details of the process design and supporting software. In healthy corporate cultures, they're also restricted to situations where the process doesn't fit. They aren't used to placate whoever has the loudest voice and worst temper. More flexibility, greater value

Traditional IT organisations won't institute process-bypass processes. They'll see no need for them. They'll operate according to their formal process designs, while negotiating service-level agreements, aka arm's-length formal contracts with the rest of the business. So long as each process satisfies its SLAs, IT has delivered on its contractually defined responsibilities. In IT's eyes, everything is copacetic. In everyone else's eyes, IT is a stifling, choking bureaucracy. Next-generation IT leaders will embrace process-bypass processes, because they understand three fundamentals of organizational dynamics: People are involved, relationships matter, and no process design is optimal for every situation it has to handle. Next-generation IT is all about business and IT collaborating to create value for real paying customers. Collaboration requires trust and healthy relationships - something SLAs can't deliver. This doesn't mean you get to ignore the efficiencies and predictability that come from well-designed processes. It means you think of them as tools, to be used when they're appropriate for the job, not to redefine the job if it doesn't fit the apparatus. Brown is InfoWorld's advice line columnist

Join the newsletter!

Error: Please check your email address.

Tags management

Show Comments
[]