IT projects are doomed from the start. With the volatile mix of shifting priorities, new unforeseen issues and a constant need for faster, cheaper solutions. This post on Ashford Global looks at how this environment has made ITIL ® seem like a great solution – ITIL promises to fit the needs of the business and speed past any traditional hang-ups that are experienced. However, therein lies the problem: ITIL can't get an organization to 100% project success, and ITIL isn't a magical cure for that truth. Furthermore, organizations generally don't use ITIL across all projects – instead picking and choosing what projects are “important” enough to include, much as this example organization mentioned in the article:
The big issue was that the organization took pride in saying “we do ITIL” because they had run a project to define and implement ITIL. The problem was that this project suffered, like all other projects, from scope creep. Budgets change, and that means scope changes follow inevitably. Sure enough, the project was re-classified, and instead of doing ITIL across the board, some systems were identified as not being important enough to be ITIL'd. The thinking said if it's a legacy system, it can't be that important so let's leave it alone. Let's not capture the critical data, the configuration details, the operating procedures and anything else to ensure we can continue to operate this system.
In the example, a small team uses its own email system to communicate. Since it's such a small team and has little impact on the rest of the business, it's excluded from the efforts of bringing projects under ITIL. Eventually that email system becomes troublesome, and the danger spreads to any system that comes close to it – directly affecting not only the small team but the entire organization, and that's the problem: ITIL could both save and hinder an organization depending on how well it's implemented and how intelligently it's employed.