Where well-intentioned ITSM implementations go wrong
Change management easily becomes a nightmare for all of IT. While most workers agree that some level of control and documentation is necessary, the implementation of ITSM involves much more than most IT organizations expect. These process improvements put reviews, documents and safety guards in place at multiple levels in the entire development and operations app lifecycle process, as well as for other IT groups. While management envisions the benefits of these new processes, the staff sees barriers to getting the job done.
Imagine exactly how many new processes could be put in place: The core of the ITIL process is divided up into three categories with multiple steps and checkpoints in each one. Development, planning, audits, control, quality assurance (QA), testing — the list goes on — require unique stops along the process chain. Ideally, different staff members should complete each of the steps — for example, to prevent a software developer from QA-ing her own code.
Even if you can ignore the prohibitory expense of hiring an army of IT pros to complete these unique steps, there’s the prohibitory expense of time. What will they do when there are no changes to approve? A large staff with a breadth of singular focuses becomes a drain on resources. Upfront staffing costs are an issue, but the time it takes to complete all of the new processes is more pressing. Every break point, document or sign-off increases the length of the change process. Something that could be done in hours can now take days or even weeks.
Management — the likely source of this ITSM implementation — will be the first to complain that it takes too long to get anything done in IT. This common scenario leaves developers, operations and the rest of IT between a hard place and a brick wall as they complete more and more forms and work continues not to get done.