ITIL 4: Why are Practices better than Processes?

The name game

Shakespeare famously asked, “What’s in a name?” In Romeo and Juliet, the names in question are Montague and Capulet, and those clashing surnames (and their associated history) result in people being killed. Best Practice frameworks are, thankfully, less likely to cause deaths, but they do become tangled in names. Before entering into the processes vs practices debate, notice that frameworks do steal words and use them in unnatural ways: scrum, sprint, and problem are all good examples. This confuses those who know what the word means in the broader world – especially when senior management relates the word to its actual world meaning. A common example is when a CEO hears “sprint” and thinks athletics – one short, top-speed burst. Yet, good agile/scrum IT shops continue indefinitely, one sprint after another (iteratively). To a track athlete, it’s more like distance running. Agile should be aerobic IT, athletic sprints are inherently anaerobic. 

Actually, those of you with teenage children will be aware that hijacking words and giving them new esoteric meanings isn’t confined to an IT environment!

What is a practice?

Clarifying concepts with simpler words is good, but ITIL 4 has not just changed the word: it isn’t as simple as “for ‘process’ read ‘practice’ throughout.” It’s more than that.

  • The processes and the functions described in ITIL V3 are now covered as practices in ITIL 4. This avoids a common source of confusion between ITIL and life. Many organizations did what ITIL V3 referred to as processes, but also had functions with the same name. Just think, your capacity management team’s role and responsibilities are not an exact fit with what the capacity management process does. Other teams have their contribution, and the capacity management people will find themselves doing things that suddenly appear in other parts of ITIL. Replace “capacity” with just about any other ITIL v3 process and you’ll have the same situation.
  • It lets ITIL 4 use the word process to refer to processes. Process is a useful term that ITIL 4 does use: “a set of … activities that transform inputs into outputs.” Practice is “a set of organizational resources designed for performing work or accomplishing an objective.” Just those definitions reveal that process is what is done, practice is about who does it and how. It means “practice” is more similar to V3’s “function,” but with one excellent addition. This set of resources has now been “designed” to do the job!
  • By separating the practices from the core ITIL 4 structure, the Service Value System (SVS), they become a set of tools and techniques to help us deliver, tools that we can choose as required (or not) to do the specific, current jobs. No particular practice is linked to any SVS element. Crucially, they are now our tools waiting to be used – not mandatory aspects we must have. To be fair to ITIL V3, the processes were never meant to be linked to lifecycle phases, but how it was packaged in books, taught and examined too often made it seem that way. ITIL 4 has used the name change to make that clear.

Practices in context

That clever wordsmithing provided ITIL 4 with an opportunity to set the range of practices, unrestricted by mapping them onto a simple ITSM picture. We now have 34 practices across three groups. These groupings help us recognize the origin of a specific practice and how best to apply it. The practices are arranged in alphabetical order within each group, to indicate there is no implied hierarchy or priority to them.

  • General management practices

These practices have broad applicability, filled with concepts, ideas and approaches that have been built from – as the name implies – general management. They are being used across other parts of an organization, indeed, they are probably owned and controlled with ITSM. ITSM will use them, but it also means there are opportunities to share skills, approaches, techniques, supporting tools and more with the rest of your company – economies of scale and resilience too, and every reason to seek consistency across the enterprise too. Seeing this list, recognizing how important the practices are to ITSM, but also recognizing their wider applicability helps strongly reinforce how ITSM is an integral part of a bigger enterprise picture and must collaborate on perfecting and delivering expertise in these practices. Any ITSM organization that tries to build one of these to apply only to its own space has, quite simply, misunderstood the situation.

  • Service management practices

These practices are more the “meat and drink” of service management, they reflect the tools we have used directly within ITSM for many years to do our jobs. Be careful though, even here, because ITIL 4 does not call them “ITSM practices.” It calls them SM practices, helping to make the point the services you are managing will have a larger composition than just IT elements. No surprise that more than 40% of them include the word “service” in their name, and all should be familiar to experienced ITIL process followers.

  • Technical management practices

These few practices are firmly at the IT end of the perspective – about building, managing and updating the infrastructure we support and use, not that this makes them easy or unimportant. Remember, one of them is “software development and management”: the full-time job of millions of people in the IT space. They are (mostly) focused on delivering what has been established as a need, requirement or desire – not establishing those needs, etc.

ITIL 4 practices

Nothing is clear cut

As with all best practices, these practices are an interpretation of a wide range of real-world situations. They have value, but they aren’t meant to be didactic rules. Look at the list of practices and their arrangement and you will, no doubt, find something you would have done differently. That’s good, and probably in your organization, you will do it slightly differently. The walls between the three groups are not high, impassable fences: they are just indicators of major relevance. Each SM practice will have some degree of wider applicability, each general practice will need specific adaptation to deliver ITSM value, and the technical practices must reflect what other practices have established. Feedback between them won’t be enough, involvement and understanding are needed (maybe we could call that DevOps?)


At its simplest, ITIL 4 has replaced the previous versions’ words of “process” and “function” with “practice.” That alone has value, in making the old terms available to assume their ordinary English language meaning, because those ideas are relevant. ITIL 4, however, has done more and taken advantage of the change to show how the range of practices are applicable across the full spectrum of ITSM, IT and the enterprise itself. The term also allows us to realize that knowing what is needed to be done (what the process must deliver) isn’t enough. We must also be sure we have the people, skills and other resources necessary to make it all work.

Blog cover by Srinivasan