The Rise and Decline of the ITIL v3 Service Lifecycle
In 2007, when ITIL v3 was first released, one of the “big ideas” in the ITIL framework was that of the IT Service Lifecycle. For more than a decade, it was the anchor of many ITIL concepts; and ITIL processes all fell under one of five phases or stages. As a training organization, we taught the five phases, and our students could recite them by memory. The idea behind the five phases told a clear story of the life that a product or service takes. And yet, there were constraints that the concept brought about; and as more modern ways of working started to expand across industries, the concept couldn’t keep up. With the release of ITIL 4 in 2019, the concept of an IT Service Lifecycle is no longer discussed (see our ITIL 4 Complete Guide for a comprehensive overview of the changes in ITIL 4). This article will delve into the reasons behind the shift and discuss which concepts have taken its place.
A Quick Overview of the ITIL v3 Service Lifecycle
Let’s step through a quick refresher of what the Service Lifecycle is (before I then tell you to promptly kiss it goodbye forever). ITIL v3 introduced the concept of the IT Service Management Lifecycle along with five phases (Service Strategy, Service Design, Service Transition, Service Operations, and Continual Service Improvement); and books were released internationally in several languages, one for each of these five ITSM lifecycle phases. It’s important to understand the makeup of the five phases along with the processes discussed in each phase, as we will bridge these concepts to ITIL 4 later on in this article.
ITIL v3 Service Lifecycle
Service Strategy: Answering the Who, What, and Why
Service Strategy was the phase where we answered questions like, “Who are our customers?” or “What do they care about and why?” It’s in strategy where we crafted our vision of what we’re trying to achieve, built strong relationships, and compared all new, great ideas against our strategy to determine whether and/or how they fit into our mission or vision for the organization. Within Service Strategy, we had processes like Financial Management (to help ensure we’re making good decisions with our budget and how much we spent on services), Demand Management (to make sure we could plan for and keep up with the demands for services from our customers), and Portfolio Management (to facilitate a good mix of products and services in what we’re delivering to our customers).
Service Design: Answering the How
When we decide to pursue an opportunity, it often goes into some stage of planning, gathering detailed requirements, and design. That’s where the Service Design phase came in. It’s here where we figure out how to turn a great idea that aligns with our mission and vision into reality. It’s often within Service Design where a project or product team would start to get involved. Within the Service Design phase, we had processes like: Service Catalog Management (where we would start to think about how we would make this product or service available to customers – for example, as part of our self-help portal), Service Level Management (where we start to define SLAs and the Availability, Capacity, Continuity, and Security targets that would be included within them), and Supplier Management (which helps us ensure our vendors meet their commitments to us, so that we meet our commitments to our customers).
Service Transition: Building and Releasing Our Products and Services
When we start to build something and get it “ready” for go-live, that’s typically when we would see it in the stage of Transition; and we would move it, essentially, from one state to another. In this case, we would move our product or service from development to operations; and our goal was to maintain a smooth transition. In this phase, we saw processes like Change Management (which helped ensure we collaborated and communicated on changes to lessen the risk of failed changes and other unwanted, negative impacts), Configuration Management (which helped us maintain control around the stuff we cared about and understand how key components like servers, switches, and applications were connected to one another), Release and Deployment Management (which, in Agile and DevOps environments, we might separate out), and Knowledge Management (which helps us transfer our knowledge to the people that need it).
Service Operation: Supporting Our Products and Services
The Service Operation phase focused on delivering “live,” ongoing products and services well. This phase included processes like Incident Management (making sure that when stuff breaks, we can quickly get customers back up and running again), Request Fulfillment (promptly handling the day-to-day, standard requests we receive from our customers and users like resetting passwords and onboarding new employees), Problem Management (which carves out the time to analyze and understand the root cause of recurring and other critical issues), and Access Management (which gives the right people in our organization access to the right stuff).
Continual Service Improvement: Improving Our Products and Services
The goal of the Continual Service Improvement (CSI) phase (and this continues to hold true with the Continual Improvement practice in ITIL 4) was to help us align with our customers’ ever-changing needs and make sure we’re keeping up. This phase was concerned with putting an intentional focus on getting better as an organization and tackling all facets of how we serve our customers – from processes to technologies to our culture, roles, and structures in our organization. The CSI phase didn’t really have any ITIL processes contained within it, however, it interacted with all of the ITIL v3 processes; and the CSI book contained a lot of tools and techniques (a variety of assessments, techniques like SWOT analysis, etc.) to help organizations improve how they work.
The Problem with the ITIL v3 Service Lifecycle
The Service Lifecycle was created to help us organize our thoughts around the kinds of work we generally performed and when. Its intent was to help organize the 26 ITIL processes released as part of the ITIL v3 library. In some ways, it served as a helpful checklist when thinking about, for example, the design of a service. When used this way, it could remind us to think about how that service was going to be measured after it was released into the wild (and start designing our SLAs early on). Unfortunately, the intent of the Service Lifecycle didn’t quite align with how it was used. It created a lot of confusion among students and ITIL practitioners alike, resulting in less-than-great results.
Invariably students in an ITIL v3 Foundation course would ask whether ITIL processes cut across the five phases, and my answer was always a resounding, “YES!” If, for example, you think about Knowledge Management, this kind of work should not be something we only do when we’re transitioning a service over to another team. Quite the opposite, in fact. Knowledge is something we should be creating and sharing throughout the organization at all times. Continuous learning is critical to creating nimble, collaborative, and happy teams and organizations. However, by placing the Knowledge Management process squarely under the Service Transition phase, it constrained how people viewed it.
Further, countless organizations viewed the five phases as a sequential way of working. As a result, two negative side effects were often encountered. First, teams tended to take on a perfectionist mentality as they created new products and services or changed existing ones. Teams often ended up working in a way that the project management industry has coined “waterfall,” creating unnecessary handoffs, rework, and delays.
Second, organizational improvements tended to focus solely within a single process or phase. ITIL practitioners focused, for example, just on improving Incident Management, Problem Management, or Service Operations in general. Organizations also began viewing each of the phases as discrete areas of practice and created rigid titles, teams, and even separate departments to handle the work associated with each of the five phases. This approach, unfortunately, entrenched a more siloed mentality amongst teams and further slowed down the pace of work, angering managers and customers and souring everyone on the idea of ITIL.
However, this issue with project phases is not unique to the ITIL framework. The same issue was seen when the Project Management Institute (PMI) rolled out the “big idea” of phases in the Project Management lifecycle. Even though the Project Management Body of Knowledge states each phase should be thought of as iterative, people still continued to see it and treat it as a sequential, rigid way of working. Many organizations, project managers, PMOs, and project teams even went so far as to come up with rigid “phase gates” that worsened the problem of project delays and bureaucracy.
The Replacement: The Service Value System and The Service Value Chain
Let’s talk about the ideas that replaced the concept of the Service Lifecycle with the release of ITIL 4, which allow us to look at this concept through a new lens. The first is that of the Service Value System (pictured below).
The Service Value System (SVS)
The SVS shows the high-level forces within any organization that hinder or help our ability to deliver great products and services to our customers. These forces are Governance (how well we manage ourselves and provide guardrails for work getting done), our Guiding Principles (the values and beliefs we live by), the Service Value Chain (more on that later), Practices (there are 34 of them in ITIL 4), and Continual Improvement (the most successful organizations are obsessed with continually getting better).
The goal is not to work on one particular area, but rather to look at how we are working as an entire organization (not as individual teams, departments, or silos, but rather as an overarching “system”) and to examine how effectively we are going from the left-hand side of the diagram (when opportunities and demands present themselves) to the right-hand side (bringing value to those we serve).
Service Value System
The Service Value Chain (SVC)
The SVC is a component within the overarching SVS and helps us understand how work gets done. It’s also a tool that can help us discuss how we deliver our products and services with our key value streams. The SVC, because it speaks to the work that is done, looks most similar to the ITIL v3 Service Lifecycle, though the two concepts are not exactly the same. Let’s look at the six key activities outlined as part of the SVC: Plan, Improve, Engage, Design and Transition, Obtain/Build, and Deliver and Support, as pictured below. You may notice that several of the activities sound a lot like the phases in the Service Lifecycle. However, these activities do not happen in any particular order. Further, specific ITIL practices are not “home-roomed” or “shoe-horned” into particular activities like they were in the v3 lifecycle. In fact, many of the practices cut across several activities, depending on the situation.
Service Value Chain
The activities within the SVC happen in whatever order and in whatever frequency that makes the most sense, and we often jump around within and across activities as we’re working to deliver products and services. Across the bottom of the diagram, the dotted lines and arrows show that, in co-creating and collaborating on products and services with our customers, there will be a lot of feedback that informs future activities and iterations of products and services throughout the process.
Further, the SVC (unlike the traditional Service Lifecycle) focuses on the goal – getting relevant and valuable products and services into the hands of our customers as shown on the right-hand side of the diagram. That’s the reason we do what we do. Yes, the work we do helps us achieve that, but it’s not the goal. Our activities only help define how we get to that goal; and each organization is going to work differently and take different paths to get to that goal. Some may be more streamlined in how they work than others, but we’re all (hopefully) trying to get to the end goal of delighted customers. This concept, along with that of the SVS, are discussed as part of a 2-day ITIL 4 Foundation course and exam. If you’re ITIL v3 Foundation certified, it’s worthwhile to get up-to-speed on these and other ITIL 4 concepts by taking the course.
What happened to all of my ITIL v3 processes?
The good news is that 95% of the processes we’ve mentioned in this article are a part of the ITIL 4 library (with the exception of Demand Management, which was treated a bit differently and is a great topic for another article). The only difference is that processes are now called practices, and there are far more of them than existed in ITIL v3 – 34 practices, in fact. There are also a tremendous number of new tools, techniques, modern ways of working, and other compelling and useful ideas in ITIL 4 (for example, around Lean, Agile, and DevOps) that did not exist when the ITIL v3 books were written.
How the ITIL v3 Service Lifecycle Maps to ITIL 4 Certifications
In ITIL v3, there were five 3-day lifecycle certification classes, one for each of the five phases, where you got a chance to dig into the specific ITIL processes in each phase. These intermediate classes in ITIL v3 have been replaced by a different set of six ITIL 4 advanced classes, which contain lots of new concepts that were not covered in ITIL v3. Let’s walk through how each of the ITIL v3 Service Lifecycle phases now maps to courses in the ITIL 4 certification schema.
Service Strategy (SS)
- Digital and IT Strategy or DITS (which discusses Strategy Management, crafting a compelling vision, Organizational Change Management, etc.)
- Direct, Plan, and Improve or DPI (which tackles Financial Management, Portfolio Management, metrics and measurements, etc.)
- Drive Stakeholder Value or DSV (which delves into Relationship Management, the customer journey, etc.)
Service Design (SD)
- Create, Deliver, and Support or CDS (This course covers most of the ITIL v3 lifecycles phases. Specific to Service Design, it discusses Security Management, Service Asset Management, Configuration Management, Availability Management, etc. in support of value streams)
- High Velocity IT or HVIT (which goes into more rapid development tools and techniques than ITIL v3 ever did including microservices, containerization, infrastructure-as-code, Kanban, etc.)
Service Transition (ST)
- CDS (This course also covers Change Enablement, Service Asset, and Configuration Management in support of value streams)
- HVIT (This course covers Release Management and Deployment Management, which are now two separate practices, as well as several other tools and techniques like Toyota Kata, retrospectives, DevSecOps, etc.)
Service Operation (SO)
- CDS
- HVIT (which covers key tools and techniques that drive resilient operations including AIOps and Site Reliability Engineering)
Continual Service Improvement (CSI)
- ITIL 4 Foundation
- DPI (which spends a lot of time talking about how to implement, lead, and improve how Service Management is done within an organization)
- Continual Improvement Practice Guide (AXELOS provides electronic versions of the 34 Practice Guides as part of their MyITIL program. Anyone that’s taken an ITIL 4 course and passed the exam receives a free subscription to MyITIL for one year. After that, the cost of the subscription is $50 annually.)
For a deeper dive into the specific topics covered as part of each of the ITIL 4 advanced courses (as well as an overview of who should attend each course), check out the link here.
To recap, we covered everything you need to know about what the ITIL v3 Service Lifecycle was, what some of the challenges were with the concept, and some of the great stuff that’s replaced it in ITIL 4. Best of luck to you in your ITIL journey!