I have another ITIL Myth to share:

By following ITIL processes, you will automatically get the results you want.

Results and process are not necessarily compatible. Often, a company wishes to follow an ITIL framework because they are not getting an outcome, such as cost savings or efficiency that they desire. The key point to remember is that the desired outcome should dictate the process, not the other way around. In addition, the process must achieve the desired results in an effective and efficient manner, otherwise it may be time for either a redesign of the process or a change in desired outcome. While this seems rather academic, often neither is easy to do.

Posted by: Eric Feldman | January 15, 2009 10:13 PM

Having been around the ITIL space for about 10 years and working at Anderson Consulting/Accenture, Kintana/Mercury Interactive/HP and now CA, I’ve seen a lot as well.

To add to your list:

Myth #4: ITIL tells you where to start.

One of the first shocks IT practitioners may receive when researching ITIL is just how big it is. They will discover that ITIL spans seven volumes -- and if they continue to dig, they will find another 34 ITIL volumes that are no longer in print but available for purchase on three CD-ROM sets. Understandably, many find this overwhelming and abandon their ITIL investigation.

Of those who do become proficient in the ITIL framework, many remain very frustrated about where to start implementing ITIL. I recall working with an IT director who embarrassedly admitted that after reading more than 50 presentations on ITIL implementations, he still was at a loss at where to start. Worse, he wasn't sure whether bringing in an external consultant for a risk assessment would achieve his IT process improvement objectives. He is not alone in his frustration.

Kevin Behr, chief technology officer of IP Services, said, "If someone is hearing voices in their head, hopefully you can do more than just pointing them to the library and telling them to read lots of books. Because ITIL is not prescriptive, many find themselves asking what they're supposed to do first."

Happily, you do not need to know all of ITIL to get benefits from it, nor do you need to understand it all to get value. To get started with ITIL, many IT practitioners will start with existing process areas that they already have and want to improve. Most commonly, these will be the key process areas at the core of almost any IT operation: change and configuration management.

In ITIL, these areas are covered as part of the Service Support volume, more popularly known as the "Blue Book." In addition to change and configuration management, the Service Support volume also contains sections covering incident management, problem management and release management processes.

Some ITIL purists may argue that the full value of ITIL cannot be realized without a fully accurate service catalog, a centralized service desk, and a comprehensive configuration management database. However, most organizations will benefit from improving their existing operational processes before tackling a full service view of IT, which typically will require an executive-level sponsor for organization-wide change.

Myth #5: Change management is just for developers.

Another challenge facing IT practitioners is ITIL process terminology sounds very similar to that used in software development. For example, for decades software developers have used terms such as "change and configuration management" to articulate how code changes are versioned, coordinated, reviewed, and released. These are well-documented disciplines described in the Capability Maturity Model, developed by the Software Engineering Institute in the 1980s.

However, as many IT practitioners can painfully attest, you can have world-class developers using world-class change and configuration management, but still have horrendous service levels because of poor coordination with IT operations. Changes and updates made by developers may fail, resulting in large amounts of "break/fix" fire-fighting, finger-pointing, and a continuing non-productive relationship between IT operations and R&D.

International Data Corp. says that 78% of all downtime is caused by changes made by duly authorized IT personnel. In order to achieve high availability and reliability, production changes must be managed. Without it, you have extremely little ability to achieve any predictable level of service. There are many places where changes come from, of which software development is only one -- other changes come from patches, maintenance releases, outage remediation and hackers.

An IT operations group is very fortunate when they can work with a mature R&D organization that has good change management processes in place. In these situations, the R&D team will work the IT operations release management and change management teams to coordinate and orchestrate how software releases are deployed into production.

Posted by: Ashish Verma | February 18, 2009 12:49 PM