Ok its 2017 and ITIL is our primary framework in our IT Operations and its sprinkled across parts of the business. Now what? Many of the common themes I’ve seen is that we are an ITIL shop and we must follow what the book says. I’ve seen so many organizations follow the book step by step only to find rigidity with the process, people and customers. While some companies may have customized their processes to be an ITIL standard, Enterprise IT often gets side track of its initial purpose – offering services to the customer.
One of the common behaviors after ITIL is implemented, is the conflict of ownership. In some cases, where boundaries are unclear, there needs to be a continuous conversation of whether a process is manual or automated. A second factor, is this new process maturing or setting us back a step? often times the conflict in ownership sets apart the processes and tearing that relationship between the already functioning parts, impacting the services to the customer.
A second common theme is documentation. Documentation is a dreadful word for all engineers and developers. An organization with a firm control of documentation often gets side tracked in managing the documentation rather than providing the actual troubleshooting and monitoring the service. Because thats what technical folks do. Leadership has some understanding of whats going on underneath the covers, so documentation is pushed heavily. Then what happens? Lets hire analysts or less costly employees to write these documentation and eventually train them to take over the system as a backup. The failure in this scenario, succession. There is no succession plan. After years of turn over this process fails because initiatives change, middle managers are re-orged and eventually nothing ever gets done. Then on to the next framework.
Incident and Problem Management are not the same processes. Many organizations have treated these two on in the same. So there are duplicate efforts in managing tickets and administrative efforts communicating what happened in the incident ticket only to re-explain the same thing in the problem ticket. Please re-evaluate these two roles and focus on the value that they provide. I hate to say “value proposition” but the value that problem management offers is much different than incident. Focus on how we can get services back up quick or through redundancy. Incident management should collaborate with Service Desk on how to manage tiers of service. Problem Management should not resolve each incident, rather a trend analysis of the environments and configurations.
Change management is a heavy process. To what level do we manage change? Some companies manage documentation maturely but not software and vice versa. Change management is the core of many ITIL processes. How do we manage it and where do we go from here? First, I would ask, how many formal change processes does your organization track? Do you find multiple change management policies for example internally and at the vendor level? It maybe worth identifying the effort of change management and creating boundaries (scope) within each team.
Distinguish activities between your sand box, test environments, production environments, and other. Why? traceability, reporting and managing the bottomline. Can you simply pull a report to identify how many incidents are reported in non-production environments. Distinguishing what unique data fields will save some headache on the long run. We often worry about production environments because that is what the customer sees. But identifying data sets will require minimal effort to distinguish these environments in a report. This will help build your case to the customer and executive leadership on how to proceed or make decisions on needed environments or disaster recovery.
Lastly, understand your data early on. RE-evaluate the value of each report and the purpose it provides. Challenge each metric. Many organizations often provide numbers for reporting only, which has no quantifiable evidence that the customer is receiving services correctly. Breakdown each metric and ensure that they are aligned to each service. I’ve seen too many reports that go up to management and focus solely on quantity of transactions with no purpose but for production or to show “we did something” The reality is the transaction do not define the quality of work. One example of a good quality measure is, how many software changes have caused incidents within the last month? This focuses on the quality of the build, the process, and how it was deployed. This covers so many facets to the IT infrastructure. Another example is, how many problems were resolved that improved services and increased transactions for the customer. Always continue to relate these metrics for our customers, its the real value thats provided for the service.