The ITIL 4 Foundation publication and exams were released in February 2019, and I hope that you have seen some information about this new version. But if you haven’t, then reviewing some of my earlier blogs should help:
In this blog, I am going to tell you all about the 34 practices that are described in ITIL 4. I will explain why they’re called practices and not processes, and I’ll tell you what’s completely new (to ITIL) and what has changed significantly.
Why the change from a focus on processes to an emphasis on practices? In previous versions of ITIL, a process was just a sequence of activities, but in ITIL 4 a practice is something you can do because you have all the right resources, including the processes that you need.
The previous version of ITIL included descriptions of 26 processes. Each of these processes described a flow of activities, as well as providing information about suggested roles, metrics, and other process-related information. Examples of processes include incident management, problem management, and availability management. ITIL 4 includes information about all of these, as well as introducing many new topics, but it calls them practices, rather than processes.
ITIL 4 introduces the idea of the four dimensions of service management. These are the four dimensions you must include if you want to describe everything that needs to be managed to enable an organization to deliver valuable products and services and to co-create value with its customers and users. They are:
The four dimensions can be thought of as perspectives, or lenses, through which you should look at all your work. One of the four dimensions includes processes, but they’re only part of what you need to manage if you want to do a good job. You can read more about these four dimensions in my blog, Everything You Officially Need to Know About ITIL 4.
We describe every practice in ITIL 4 from the perspective of these four dimensions of service management. Each practice can be thought of as a capability, something you can do as an organization. For example, your availability management practice will probably include one or more processes, but it will also include resources from each one of the four dimensions.
It’s important to note that these practices are NOT intended to be carried out by specific organizational entities. They’re capabilities. Some practices may require one or more dedicated teams, but others will typically be spread around several existing teams. One implication of this is that the ‘organizations and people’ domain for each practice needs to describe how that practice is mapped to the organizational structure.
ITIL 4 describes 34 practices.
Here’s a list of the 34 ITIL practices; I’ve highlighted in orange the practices that are new or significantly changed, from ITIL V3, and I’ll describe these in a bit more detail later. I should point out that even the practices that I haven’t highlighted have changed since ITIL V3, so do read the new ITIL 4 Foundation book to learn about them, but the highlighted practices are the ones with the most significant changes.
General Management Practices
Service Management Practices
Technology Management Practices
Some practices are new to ITIL 4. Either they weren’t described at all in ITIL V3, or they were mentioned, but not as processes. Of course, ITIL 4 hasn’t just invented the new practices it describes. Most IT organizations were doing at least some of them, but they weren’t well covered by ITIL. Other practices that did exist as ITIL V3 processes have changed significantly.
Architecture management helps the organization to understand all the different elements they use, and how these interrelate. The scope of this practice includes business architecture, service architecture, technology architecture, and environmental architecture.
This practice was partially described in ITIL V3, but not in a consistent and coordinated way. The purpose of this practice is to support good decision-making and continual improvement, by collecting and assessing data in an appropriate context. The scope includes products, services, practices, activities, teams, people, suppliers, and partners.
ITIL V3 included a description of organizational change management in chapter 5 of ITIL service transition, but it wasn’t described as a process, and many people ignored this chapter!
The purpose of this practice is to ensure that changes in an organization are smoothly and successfully implemented, and that lasting benefits are achieved by managing the human aspects of the changes.
ITIL V3 included a service portfolio management process. The scope of this has been considerably expanded to include programmes, projects and products, as well as services. This practice considers the funding and resource constraints within the organization and ensures that resources are assigned appropriately.
ITIL V3 did not describe project management, although there were occasional references to projects in the ITIL V3 books.
Projects are described by ITIL 4 as “the means by which significant changes are introduced to the organization” and the purpose of the project management practice is to ensure that projects are successfully delivered by planning, delegating, monitoring, and maintaining control of all aspects of projects, and by motivating the people involved.
ITIL V3 included a business relationship management process. The scope of this has been significantly expanded to cover relationships with all stakeholders, not just customers.
The purpose of the relationship management practice is to establish and nurture the links between the organization and its stakeholders at strategic and tactical levels. This does not include operational relationships, which are typically managed by a service desk.
Many ITIL V3 processes were involved in management of risks, but there was no overarching risk management process. The risk management practice ensures that the organization understands and effectively handles risks as an integral part of all organizational activities.
The purpose of this practice is to ensure that the organization has the right people with the appropriate skills and knowledge in the correct roles. This area was very partially covered in ITIL V3 capacity management but has been considerably expanded and described as a separate practice in ITIL 4., which states that it “should be the responsibility of leaders and managers at every level throughout the organization”.
Identifying service requirements was described in ITIL V3 Service Design, but not in the context of a process and without reference to the common industry term “business analysis”.
The purpose of this practice is to analyze a business, or some aspect of it, define its needs, and recommend solutions to address those needs and/or solve a business problem.
ITIL V3 described a change management process. The name has been changed to avoid confusion with organizational change management, which is called change management in many organizations. The scope of change control has also been changed. It no longer includes investment decisions, which have moved to portfolio management.
The purpose of this practice is to maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing a change schedule. One significant change to this practice includes a much greater emphasis on delegation of change authority, away from centralized decision making.
ITIL V3 included a process called ‘service asset and configuration management’ that briefly described the management of IT assets, but mainly focused on configuration management. This has been split across two different practices in ITIL 4. IT asset management, and service configuration management.
The purpose of the IT asset management practice is to plan and manage the full lifecycle of all IT assets to help the organization maximize value, control costs, manage risks, support decision making, and meet regulatory and contractual requirements. An IT asset is defined as “Any financially valuable component that can contribute to the delivery of an IT product or service”.
ITIL V3 included a process called ‘release and deployment management’. This has been split across two different practices in ITIL 4. Release management, and deployment management.
The purpose of the release management practice is to make new and changed services and features available for use. Depending on the technology in use, and the organizational policies, releases may be combined with deployment, with the new functionality becoming available as soon as it’s deployed, or there may be a significant separation of these activities, with many deployments taking place each day, but releases being controlled by feature flags, blue/green releases, or other mechanisms. (If you’re not familiar with these terms then you may need to read some DevOps blogs or at least read the ITIL 4 Foundation publication).
This is the other part of the ITIL V3 ‘service asset and configuration management’ process. (See IT asset management above).
The purpose of service configuration management is to ensure that accurate and reliable information about the configuration of services, and the configuration items (Cis) that support them, is available when and where it is needed.
This is the other half of the ITIL V3 ‘release and deployment management’ process (See ‘release management’ above). The purpose of deployment management is to move new or changed hardware, software, documentation, processes, or any other component to live environments.
There have been significant changes in this area based on improvements in the technology used for deployment in many organizations.
ITIL V3 included a technology management function, that described how infrastructure should be managed. ITIL 4 describes this as a practice, in the same way that it describes all other organizational capabilities.
The purpose of this practice is to oversee the infrastructure and platforms used by an organization, including those provided by external service providers.
Software development was outside the scope of ITIL V3. Software management was described in the application management function.
The purpose of this practice is to ensure that applications meet the needs of internal and external stakeholders, in terms of functionality, reliability, maintainability, compliance, and auditability. ITIL 4 does not describe how to develop software in detail, but the addition of this practice allows ITIL to describe everything needed to co-create value, and how these things work together in value streams that connect demand to value.
ITIL 4 Foundation describes 34 practices. These practices include everything you need to co-create value with your customers and other stakeholders. Although the descriptions are brief (ITIL 4 Foundation only provides a few pages of description for each of the 34 practices), they do provide a balanced description of each practice that includes organizations and people, information and technology, suppliers and partners, and value streams and processes. A more detailed discussion of the ITIL 4 practices is due to be published later this year.
The scope of ITIL 4 practices is significantly wider than the ITIL V3 processes that they replace, and they’ve been updated to reflect changes that have taken place in the industry over the last few years. These practices are much less prescriptive than the ITIL V3 processes, because every organization is different and no one approach is going to be right for everybody, but they do give you a great starting point if you want to improve how you manage services, and how you create value with your stakeholders.