I encountered a good article on the subject written by @Dan McCarthy. In the second paragraph of the article, I read something that resonated to my personal experience. I was about to do a presentation to the CIO and I was told by some of the folks in the organization not to use the acronym ITIL. I was speechless because my talk will be revolving around the value of ITIL if the IT organization adopts the practices to improve the value of IT. Dan’s paper quoted this, “Whatever you do, don’t mention ITIL”. This reminded me of another organization I know who is ramping up their project management resources and I was given a word by one of my friends who consulted with this organization that when I get to speak to their management team, don’t use the words “Project Management”. I was told to call the practice anything but not project management. There is some semblance to ITIL and Project Management. These two follow a certain protocol or life-cycle in delivering their services to the customer.
Similar to many organizations that tried to implement a project life-cycle or methodology using the PMBOK as a guide, the ITIL framework suffered negative perception. Dan mentioned in his article that ITIL is too bureaucratic, too difficult, too expensive, too complex, too restrictive, slows us down, and most recent one is that it is no longer relevant. This last reason for not adopting ITIL is entirely misleading. Pundits say that ITIL is not longer relevant due to the growth of cloud computing adoption in the SaaS, PaaS, and IaaS space at least. You have heard and read articles written about ITIL being outdated due to the DevOps practices currently in play and all other modern developments in the IT space such as the IoT. As you have read, most of the content I mentioned are all negatives. No one attempts to write the value ITIL gives to the enterprise. No one takes the time to talk about the problems ITIL helps solve. I would encourage you to read the article Dan wrote as he highlighted two areas where ITIL helps solve problems; problems internal to IT and problems in the business domain. Below is a quote of some of problems highlighted by Dan. In my humble opinion, these can be used as critical success factors when rolling out ITIL-based capabilities.
“Internal IT problems:
- How can we all get on the same page, speaking the same language, so that we can be more effective?
- Our processes are incredibly complex. It’s hard to see where they interact. We need to make their interactions clearer.
- What does it mean for the IT organization “to do better”?
- We need to be able to manage our interactions with the business across the whole IT lifecycle.
- We need to be able to explain what value we give to the business. In general, answers like “We manage 1,000 widgets” don’t work – we need to talk about the services we provide in a more meaningful way.
- How can we know if our investments have a reasonable return?
- How can we plan for future business demand?
- How can we deliver changes effectively and efficiently without tying ourselves to a single change framework?
- When things go wrong, how can we minimize the negative impacts?
- We want to invest in IT. We see its value for the organization, but we want someone else to manage the technical details effectively.
- We want to invest in IT. We see its value for the organization, but we want someone else to manage the detailed risks involved in it.
- We want IT to deliver business changes quickly and reliably.
- We want to know if we could get a better, faster, and risk-optimized return on our investments in IT.
- When things go wrong, we want negative impacts minimized.
The above is not the whole list Dan identified in his article. What is compelling is that we can have a crucial conversation with our stakeholders and tell them that ITIL can be a key problem solving feature of the Enterprise.