One of the most damaging trends i've seen in a long time in ITSM is the propensity of some users to treat ITIL more like a religion than a set of best practices.

In some sense, it's almost like the creators didn't realize the beast they've unleashed.

I've been in discussions at multiple IT organizations where various processes, tools, changes are being made not because they make sense for the organization, but because of a misguided belief that "ITIL Says we should....."

I've seen shouting matches over trivialities such as the meaning of Service Level Management, Help Desk vs Service Desk, Ticket vs Incident and many more.

Overall, despite some of its shortcomings, I like ITIL and would advocate that IT organizations should use it as a valuable reference point, and at least at a conceptual level some guiding principals.   But to take a fundamentalist approach to ITIL implementation simply makes no sense and is somewhat of a cop-out in terms of thinking about what problems the organization might have, and how they can be solved.

Instead of rigidly implementing what the books say, why not take a more general approach to ITSM and think of some of the core principles that good organizations embody, for example:

• Focus on business services, not the infrastructure
• Managing Change
• Measuring and reporting on success/failure
• Separating out getting a service working from the process of fixing root cause
• Understanding the lifecycle of services

From there, organizations can cherry pick the various parts of ITIL, other standards and things that they are already doing well, even if they don't fit the ITIL approach.

Last week I wrote an opinion piece around ITIL and I had some good feedback from a reader about how ITIL v3 introduced some improvements.

I see ITIL v3 as a bit of a mixed bag - there are some key improvements, but also some of the aspects I mentioned in the last article tarnished those improvements. So to present both the good and the bad, below are some of the improvements as I see them:

• The lifecycle approach to Service Management - This is the biggest improvement in my opinion.   Services are not static, they are created, maintained, upgraded and then finally retired.   ITIL v2 neglected this concept.   I do think V3 is very light on the development of those services - for example in a lot of the organizations I've been involved in, when the services are being developed there is little thought that goes into how they will be managed and I think this part of v3 is rather light, but at least it touches on it.
• Knowledge Management - I think knowledge management is probably the least well understood improvement as it seems that most see it as some kind of a knowledge base attached to the service desk.   There is a lot of potential to create a Service Knowledge Management System (SKMS) that addresses some of the shortcomings of the CMDB in V3; by taking the data that already exists in the organization, correlating it together and presenting it in a way that employees at all levels can use to make decisions.
• Configuration Management - Realizing that the CMDB is not the center of the universe and there could be multiple CMDBs in the same organization that need to be thought of as one federated model was a useful improvement, althought I maintain that a CMDB is counterproductive for most organizations, and unless there are specific projects like Data Center Consolidation, M&A activity etc the massive costs simply can't be justified.
• Continual Service Improvement - A mixed bag here.  I think it was valid to remove this from Service Level Management; but I'm not sure why they created a whole new process here when there are better ones like Six Sigma DMIAC available.   The new process has little content around how to sustain the improvement.
• Service Portfolio Management - Multiple improvements, for example taking into account suppliers, external service providers and so on.
• Business Service Management - An acknowledgement of the role of Business Service Management in modern IT organizations
• Other Standards and Best Practices - An acknowledgement of other standards such as CoBIT, ISO20000 and so on.

In summary, ITIL v3 introduced some useful improvements, but I see it as a missed opportunity to really focus on how IT can support business needs.

There are a lot of reasons why businesses may be draw to SaaS based applications.   One of them is that they can be a good way for the business to bypass an IT department that they view as being unsupportive or unreceptive to their needs.

IT departments need to be aware of this trend because if not managed it could significantly change the way that IT is delivered to business users, and has the potential to end up costing the business significantly more money.

IT departments need to partner up with the business when it comes to SaaS based offerings.  Instead of seeing them as a threat, they should regard them as just another way they can provide services to their users.   With some services, SaaS will make sense - it will be cheaper, quicker to set up and less costly - but this will not be the case for everything.

That means that members of the IT organization need to be business savvy enough to understand what the business users actually need (which could be different than what they ask for) and help drive the requirements for the applications (and delivery models of those applications) that support those needs.   These needs can also be rationalized over multiple departments to save cost.     To be successful, these people should sit 'with' their business counterparts and form a conduit into the IT department for understanding the changing requirements for business applications.

Without such an approach, business users now have the ability to easily go elsewhere for many of the applications they need.   An IT organization who does not understand what the business needs and is not their partner in creating the right services may find that new services are popping up in every corner of the business, with little oversight, little technical evaluation, and with little consideration for aspects such as security, performance, redundancy, standards and so on.

Business users will likely miss key steps of a SaaS provider evaluation in terms of understanding how resilient their architectures are, what the SLAs for performance and availability there are (and what the fine print really means) and so on.   Ultimately the whole company suffers in this approach.

Better led IT departments will partner up to work with the business and will build the right portfolio of services with the delivery model tied to the requirements of the service.

Security is a part of all IT environments, even if it is just simple passwords and a lock on the data center door.     Most companies (outside of highly sensitive industries) have standard security policies.   These policies, while perhaps being well intentioned, fail to take into account human behavior.   Consequently, it could be argued that the achieve the opposite of what they intend - reducing security.

For example:

There are many more examples, but the premise of this article is that when designing security policies, think about the human element. People just want to get their work done with the minimum of fuss and security is about the last thing on their mind. Why not design policies that allow them to do that, but at the same time still achieve security aims like keeping data safe, ensuring that 3rd parties cannot access that data and so on.