Sign in
  • Blog
  • Processes
  • Requirements
  • ITIL

Author  Robert Burton - Application Services Manager - Release & Configuration at Bupa - MBCS, ITIL Expert, PRINCE2 Practitioner

August 31, 2016 |

 4 min read

  • Blog
  • Processes
  • Requirements
  • ITIL


Robert Burton explains why he feels that ITIL shouldn’t be viewed as a prescriptive regime.

There is a common misconception that ITIL is a rigid set of tools, procedures, and processes and if you don't follow what’s in the books, it’s not ITIL.

With this approach, businesses try to implement and impose what they believe to be a prescriptive regime that does not marry with their organization’s unique needs. Plus, by forcing this inflexible structure upon their staff it’s often met with resistance.

Despite what some people think there is not an ‘ITIL way’. In fact, ITIL doesn’t even try to be prescriptive. I think of ITIL as a supporting framework, not as a set of rules to follow, and here’s why:

ITIL: the “scaffold for your building”

ITIL is the scaffold around a building: you construct the building around it and it supports what you’re doing. Equally, building without it can cause things to go very wrong.

The greatest resistance to using an ITIL framework comes from IT architects and developers who, in the main, don’t think it’s for them. Yet if you create a project without solid foundations and then try to move it from production and have to manage a backlog or deliver continual service improvement, there isn’t the supporting structure in place. That’s when your building will fall down.

While ITIL is a structure, it’s not a rigid one: it allows you to cherry pick what you want and what you don’t. The very nature of ITIL and the ‘adopt and adapt’ mindset encourages users to tailor the library of best practices to their needs. If something fits your requirements, great, use it. If it doesn’t, tweak it or don’t use it.

As my role involves constant problem management, that’s how I use ITIL predominantly. In fact, I think I solve 95% of my problems using the framework. When faced with an issue or a potential issue, I look at the ITIL guidance and think: “how can I fix this by plugging in the principles and methodologies?” As ITIL is descriptive rather than prescriptive, it doesn’t give me the answer but it allows me to find a way to tackle a situation.

ITIL’s ability to help users overcome problems is one of the best ways to convert sceptics. When they see how it can work, they get it. And when they get it, they adopt and adapt it.

ITIL is not just for IT

Although there is IT in ITIL (both in name and content), ultimately, it’s about service management and its principles can be applied much more broadly beyond IT.

Within my organization, we’re actually using ITIL principles in our property management team to handle and resolve property management incidents. I believe you can use ITIL in any scenario where you’re delivering a service: you could even use it in a restaurant.

As well as giving you the right mind-set, ITIL gives you a shared mindset and, because of its flexibility, this is an approach that can be used across teams and departments.

In essence, ITIL helps people to communicate in a common language, whatever their area of work, and helps them understand processes. When someone grasps what they’re doing, they stick with it and that helps to optimize the workflow, reduce costs and, critically, give a cleaner service to the customer.

See our ITIL section for more information.

More blogs in our ITIL Misconceptions series

ITIL® Misconceptions: “ITIL is only for big organizations.”

ITIL® Misconceptions: "ITIL is for infrastructure or production only."

5 popular misconceptions about ITIL®: ‘ITIL is a standard’, and other folk stories