CHAPTER 2
The Service Lifecycle
In this chapter, you will
• Learn the five stages of the service lifecycle
• Understand how new or changed services flow through the lifecycle stages
• Discover how the concept of continual service improvement underpins the effectiveness of the service lifecycle by ensuring valuable feedback from stage to stage
• Recognize the essence of each of the 26 ITIL processes and learn to which lifecycle stage each belongs
Lifecycles appear in a lot of management books, and I haven’t always been convinced by every example. The IT Infrastructure Library (ITIL), of course, is not just theory. The concept of the service management lifecycle is very relevant. In fact, I’ll go further. The concept of the service management lifecycle is of fundamental importance. Please don’t move on from this chapter until your understanding of it is clear and complete. There’s going to be a particularly important exercise for you to do later.
What Is the Service Lifecycle?
Let’s start by looking at Figure 2-1; it shows the “classic” ITIL version 3 service lifecycle, which looks like a sort of Wankel engine rotating around the axle of Service Strategy, driven by continual service improvement and comprising the sequential stages of Service Design, Service Transition, and Service Operation. That’s all good stuff, but if, like me, you’re more of a linear thinker, you may find my approach easier to understand; many of my students do. Figure 2-2 shows my concept, which clearly shows the important feedback loops. Figure 2-2 is the picture of the service lifecycle I’d like you to keep in mind throughout this book.
Figure 2-1 The service lifecycle
Figure 2-2 Lifecycle with feedback loops
The Five Lifecycle Stages
Let’s take a closer look at these five lifecycle stages.
Service Strategy
In Service Strategy, you seek answers to fundamental questions. What exactly is the business you’re involved in? Is it a straightforward drinks logistics business like Tradeteam? Is it a huge and complex government department? Is it a provider of outsourced services? The possibilities are practically endless. Whatever the business may be, the first thing a service provider has to do is to understand what the business is about. What are the aims of the business, who are the customers of the business, where does the business see itself going in the future, and so on? You must have a clear understanding of the strategy of the business. That begs another question. Does the business itself have a clear, coherent understanding of what its strategy is? Perhaps you can begin demonstrating the value of what you as a service provider bring by asking such pertinent questions to which you should, reasonably, expect to get clear answers!
Once you have the business strategy clear, you can align your IT strategy to it. You can then consider what services you can provide from your IT resources to support the business processes that are delivering the business strategy. This is a good point at which to remember the definition of service: “a means of providing value to customers by facilitating the outcomes they want to achieve without the ownership of specific costs and risks.”
At this top level, you need to define your services, link them to the business processes they facilitate, and have as good an idea as you can of the costs and risks involved. Typically you would document each of your services in an agreed-on business case. From the business case, you can then produce an outline service specification to pass on to Service Design.
Service Design
In Service Design, you carry out the detailed planning. This is where you put flesh on the bare bones of your original specifications. At the end of this stage you should have produced a detailed blueprint of exactly what will be the components of your new service, how it’s going to be tested, how it’s going to be supported, and how future development will take place. At the same time, you may uncover some shortcomings in the preceding strategy stage; those shortcomings should be referred back to the strategy stage for remedial action. Once you’re happy that your design is comprehensive, effective, and agreed on, you pass the blueprint you have created to Service Transition.
Service Transition
The Service Transition stage is where you actually build things. You acquire hardware and software. You plug it all together and make sure it works as specified. You bring the customers, users, and support organization into the picture to make sure that the new service can be successfully launched and operated in the real, live world. To that end, you test not only the programs but also every relevant aspect, including all the support arrangements, to ensure the service as a whole will be successful. You take particular care to control what is a constantly changing picture and to ensure the quality of what you roll out. Again, you may uncover some shortcomings in the two preceding stages: Service Strategy and Service Design; those shortcomings should once more be referred back for remedial action. You now have to make a crucial decision. Is everything ready? You must aim to achieve a seamless handover to Service Operation.
Service Operation
Now you reach the moment of truth. Here is where you should be showing that you are truly “facilitating the outcomes your customers want to achieve.” Urgent operational difficulties should be fixed whenever possible, and any inherited shortcomings identified at this stage should be referred back to the preceding Service Strategy, Service Design, or Service Transition stage for remedial action.
So far so good. If you have everything right in strategy, design, and transition, everything should now be working beautifully in operation. But the world is rarely like that, is it? This is where continual service improvement comes in.
You could argue that, with your new appreciation of the benefits of ITIL best practice, you should reengineer everything. Go back to strategy with a clean sheet of paper and start again, working your way through strategy, design, and transition properly this time. Unfortunately, not only would this be quite expensive, but it would also take quite some time to do. Moreover, while you’re doing all that reengineering, how would you manage the live, operational world, and what about the unavoidable changes that would still have to take place during this reengineering effort? You would probably end up with services that are still out of date after having spent a lot of time and money.
Continual Service Improvement
Continual service improvement (CSI) is relevant to all stages of the service lifecycle (including itself!). However, I usually find it most valuable to start formal CSI in Service Operation. Here is where the customer and the service provider are likely to be feeling the greatest pain. Here is where you have the opportunity to capture evidence to support your improvement initiatives. First, you should make sure you’re operating your services as well as you can. How’s your “firefighting”? Are you logging incidents when things go wrong, managing them through to resolution, and keeping a record of what you’ve done? If you’re not even doing that, you’d better get started! If you have an incident process, is it documented and up to date? If not, you should get it documented and check it is working properly. A crucial consideration now is to ascertain that in your incident records you are capturing evidence of shortcomings earlier in the service lifecycle. Was testing inadequate? Were capacity considerations not properly addressed? Was there a fundamental misconception when the service was originally conceived? CSI guides you to capture relevant evidence and then take appropriate action. You apply the CSI approach to each stage, not just to Service Operation; indeed, you even do CSI on CSI to make sure you’re doing that well.
Lifecycle Stages in Action
The following sections summarize the five stages of the lifecycle.
Service Strategy You decide which services to provide and what resources are needed by those services. You record how those services meet the business requirements, and you seek to maintain the closest possible relationship with your business customers.
Service Design You take from Service Strategy the agreed-on service specifications and produce the detailed plans for each service. Service Design ensures that you document how resources are to be combined to meet the specification and to be shared with all the other services you are running. It shows how the new service is to be tested, rolled out, and operated in the live environment. However, nothing is actually created yet other than the detailed blueprint. If the design needs to be changed, this is the time to do it.
Service Transition Service Transition handles the physical creation and implementation of the services. Infrastructure is acquired and installed, applications are developed or bought, everything is thoroughly tested against the criteria specified in Service Design, training and documentation are completed, and all this exciting stuff is rolled out into the live environment. All these changes and deployments are carefully controlled, and your configuration information is updated.
Service Operation Here you actually provide your users and customers with the services that have been agreed on with them—the services that will be “facilitating their outcomes.” You need to ensure that only authorized people can use those services, that any faults are identified and corrected quickly, and that you capture valuable evidence to support improvement programs. For CSI you need to know how well the services are being delivered, so you provide performance reports from the Service Operation stage.
Continual Service Improvement CSI underpins everything you do. It makes sure that the aim of providing agreed-on services to your customers is never forgotten. It works with every lifecycle stage to help ensure that all the activities in every stage work as well as possible, that interprocess links are effective, and that any evidence of shortcomings in other lifecycle stages is captured and passed to the appropriate manager.
The Lifecycle as Drama
The lifecycle may make more sense if I present a well-known example. How about taking a quick look at the lifecycle of the RMS Titanic?
Back in the early years of the 20th century, the White Star Line was one of the leading transatlantic shipping companies. Its business strategy was to make more money by carrying increasing numbers of passengers between the United Kingdom and the United States; its two customer segments were opulent millionaires and large numbers of cheap-fare immigrants. The service solution for which an approved business case would have been produced was the RMS Titanic. The costs would have been assessed, an outline of the size and features of the ship would have been agreed on, an expected return on investment would have been calculated, and a specification would have been given to the shipbuilders Harland and Wolff. That was the Strategy stage completed.
Harland and Wolff’s naval architect, Thomas Andrews, would have produced a detailed design of the new ship. This would have covered a wide range of elements ranging from the type and size of the engines to the number and size of cabins, crew accommodation, and even the number and capacity of the lifeboats, always ensuring that regulatory requirements were met. Andrews and his team would have produced a set of detailed blueprints. Thus, the Design stage was ended.
Now the actual work started. The structure of the ship was built, the engines were ordered and installed, and full details were documented of what was being created. All aspects were tested to make sure they worked properly, culminating in a full-scale sea trial. Only once satisfactory results were obtained was the Titanic released for her maiden voyage. The Transition stage was over.
Captain Edwin Smith took charge for the maiden voyage, and the Titanic left Southampton bound for New York. No doubt there were one or two “wrinkles” in the ship’s systems and processes that needed resolution, but most things went well until the Titanic bumped into that infamous iceberg and sank. Thus, the Operation stage came to an unfortunate, premature conclusion.
Now it’s the turn of continual service improvement. No doubt much was working well on board, until the voyage came to an abrupt end. However, it is now clear to us that some operational aspects were unsatisfactory (steaming at full speed through icy seas when the lookouts had no binoculars), and the contingency plan was bedeviled through inadequate investment in lifeboats and procedural problems when deploying them. These lessons were learned and incorporated into the Titanic’s larger sister ship, the Britannic. The fact that the Britannic hit a mine and sank on November 21, 1916, during the Gallipoli campaign is not of direct relevance.
Maybe the service lifecycle can sometimes be more exciting than we might think!
Processes and Functions
With a clear outline of the five stages of the service lifecycle, you can now fill in some essential details. You can’t go too far in this book without considering processes, and now you need to see which processes fit into which lifecycle stage. You’re also going to consider functions. It may be worth your while to remind yourself of the definitions of service and function provided in Chapter 1 before you go any further.
Let’s now do an exercise that will require you to handle the names of all the processes and all the functions and become familiar with them.
Exercise 2-1: Processes and Functions in the Service Lifecycle
It is vital to an understanding of ITIL that you are clear where each process and each function fits in the lifecycle. Table 2-1 lists the 26 ITIL processes and 4 ITIL functions. Your task is to allocate each one to the lifecycle stage to which you think it best belongs. You’ll have to guess a bit, but the point of the exercise is to get you thinking about the names of each process and where each might fit. You’ll do it step by step with me at your shoulder to help!
Table 2-1 Processes and Functions
To give you a clue, the number of processes/functions per lifecycle stage is as follows:
• Service Strategy—5
• Service Design—8
• Service Transition—7
• Service Operation—9
• Continual Service Improvement—1
Take a look at Table 2-1 to familiarize yourself with their names, but don’t start the exercise yet.
Step 1
Let’s do the easy ones first. Did you notice that some process names relate directly to the lifecycle stage they belong to? These include Strategy Management, Design Coordination, Transition Planning and Support, and Seven-Step Service Improvement? So, there are four to start with.
Let’s move on to those processes that seem to be related to day-by-day operational activities; these are processes that execute the rules made elsewhere. Again, it’s not too difficult I hope. Which ones do you think these five processes are?
Incident Management is a pretty obvious choice, isn’t it? Incidents are often triggered by events (hence Event Management), and we investigate the underlying causes of incidents in Problem Management. So, we now have three processes that fit together. You may also have guessed that Request Fulfillment sounds like a Service Operation process, and it is! The fifth process is Access Management, which manages granting and removing user access rights to applications, systems, and services (users here include IT staff and management).
Did you also notice IT Operations Management? This also belongs to the Service Operation lifecycle stage, but it is a function. Can you recall the definition of a function? A function is “a unit of organization specialized to perform certain types of work and responsible for specific outcomes.” Can you identify another function that belongs here? Yes, the Service Desk. These two functions are pretty obviously Service Operation functions. The two other functions have a wider relevance in the lifecycle but, for the sake of clarity and neatness, are also placed in Service Operation. Those other two functions are Applications Management and Technical Management.
Table 2-2 shows what you’ve achieved so far.
Table 2-2 Processes and Functions in the Service Lifecycle—Step 1
Step 2
Let’s go to the start of the service lifecycle. What processes seem to have a hint of the strategic about them? Financial Management is clearly of crucial importance, as would be a list of services. But would such a list be the Service Portfolio or the Service Catalog; which one is more strategic? It’s the Service Portfolio that’s strategic. This includes all services—live services, services in development, and retired services, so we should choose the Service Portfolio Management process. You may also have judged that Business Relationship Management sounds strategic, certainly more so than, say, Service Level Management. That leaves just one process to add. That process is Demand Management, which is about understanding the resources needed to meet the demand for services. As you examine these processes more closely in Chapter 3, I hope the link between them will become clear. Moreover, as you move through the lifecycle, you’ll also appreciate that, while these processes sit in Service Strategy, they are relevant to all the lifecycle stages. (See Table 2-3.)
Table 2-3 Processes and Functions in the Service Lifecycle—Step 2
Step 3
Now you can have a go at the Service Design processes. Remember that this stage is where you do the detailed planning.
You decided in step 2 that Service Portfolio Management belongs in Service Strategy, which therefore implies that Service Catalog Management belongs in Service Design; that is true—the Service Catalog is a detailed component of the Service Portfolio. Having thus cataloged your services, you are then in a position to produce service level agreements (SLAs); SLAs logically come under the Service Level Management process. Now, to negotiate SLAs, you need to have detailed technical information and relevant organizational policies and procedures because you need to specify how the service is to be delivered and supported. There are four processes involved: Availability Management, Capacity Management, IT Service Continuity Management (ITSCM), and Information Security Management (ITSyM). The final process in Service Design is Supplier Management, which complements particularly the Service Level Management process and the four processes just listed.
Step 4
You’re now left with six processes that you can put alongside Transition Planning and Support in the Service Transition lifecycle stage. Knowledge Management is a process that is applicable across all lifecycle stages but is found in Service Transition because this is the stage where useful, new knowledge is acquired. Service Asset and Configuration Management (SACM) can be considered as “Knowledge Management in practice” and is also relevant to every lifecycle stage. To manage your configuration effectively, you need to exercise control, which is achieved through the Change Management process, a process that is all about transition, as its name implies. Changes are implemented through the Release and Deployment Management process. Finally, the Service Validation and Testing process and the Change Evaluation process can be slotted logically and neatly into place.
You now have the full picture, as shown in Table 2-4. I suggest you bookmark this table for future reference.
Table 2-4 Processes and Functions in the Service Lifecycle—Final
Recap
I’ll think you’ll find it worthwhile to work through the lifecycle stages to make sure you have a clear picture of what goes where.
Service Strategy Clearly, Strategy Management fits here as does Financial Management. The Service Portfolio is the synoptic view of all services (potential, live, and retired) and forms a strategic big picture. Business Relationship Management (BRM) is concerned with the relations at a high management level between service provider and customer; BRM covers those who commission and pay for services. Finally, Demand Management is concerned with how much resource is going to be needed to meet the pattern of demand for services coming from the business; it links with Financial Management to make crucial inputs to business cases.
Service Design Design Coordination does what it says. The Service Catalog is derived from the Service Portfolio and covers all services that are live or are being prepared to go live. Once you have your services defined and cataloged, you can then start to negotiate SLAs and so on, which is done in the Service Level Management process. SLA targets are often dependent on Availability and Capacity Management aspects; SLAs can also usefully include IT Service Continuity and Information Security considerations. Supplier Management deals with the contracts that underpin SLAs and that may also have availability, capacity, service continuity, and information security considerations.
Service Transition Transition Planning and Support coordinates and controls what happens in this stage. Knowledge Management gives you the disciplines to ensure you capture and maintain knowledge; the Service Asset and Configuration Management (SACM) process can be considered as Knowledge Management in action. It is inadvisable to do SACM without having Change Management in place, and Release and Deployment Management can be considered in a number of ways as being a close-companion, enabling process for Change Management. The purpose of Service Validation and Testing is self-evident, while Change Evaluation is concerned with ensuring that, notwithstanding all the test criteria being met, the new service will still actually perform in the live environment as originally conceived.
Service Operation: Processes Event Management is where you keep your finger on the pulse in the live environment, detecting what’s happening and triggering any necessary action in response to what’s been detected. When service is interrupted, you use Incident Management to restore normal service as quickly as possible, while Problem Management is where you investigate the causes of incidents and put permanent fixes in place. Some events and incidents can trigger the Request Fulfillment process (which often uses change models created by Change Management). Some service requests are fulfilled by invoking the Access Management process, which executes the activities previously designed in Information Security Management.
Service Operation: Functions The Service Desk performs a lot of Incident Management activities (although it must be remembered that Incident Management is not the exclusive preserve of the Service Desk). The Service Desk is particularly responsible for assisting end users to obtain maximum value from the IT services they’re using. IT Operations Management looks after the second-by-second, minute-by-minute, hour-by-hour functioning of the technology; here is where you’ll find the operations bridge or network operations center, for example (I guess you’ll have seen a number of control rooms that look like that on the Starship Enterprise). The other two functions, Technical Management and Applications Management, get involved in lifecycle stages other than just Operations but for clarity and convenience are placed alongside Service Desk and IT Operations in the Service Operation stage.
Continual Service Improvement Every process and function has a link to CSI because every process and function is subject to continual service improvement, as you will discover later.
EXAM TIP Four of the processes are not currently in the ITIL Foundation Examination syllabus: Strategy Management, Demand Management, Service Validation and Testing, and Change Evaluation. You will not get specific questions on these four processes, but you will find that an awareness of them helps you have clearer definition of the lifecycle processes that are examinable.
Chapter Review
At the beginning of this chapter, I listed the following learning objectives:
• Learn the five stages of the service lifecycle
• Understand how new or changed services flow through the lifecycle stages
• Discover how the concept of continual service improvement (CSI) underpins the effectiveness of the service lifecycle by ensuring valuable feedback from stage to stage
• Recognize the essence of each of the 26 ITIL processes and learn to which lifecycle stage each belongs
These four points are drawn together in diagrammatic form at Figure 2-3. Please make sure you are familiar with both the content and the purpose of each lifecycle stage. Refer to this chapter if necessary.
Figure 2-3 Lifecycle stages with processes and functions
Watch Lifecycle Stages with Processes and Functions for a discussion of the processes and functions, where they belong, how they interact, and how CSI reinforces that interaction. (See Appendix D for access to this and other videos.)
Questions
1. Which one of the following is not a process?
A. Service Desk
B. Change Management
C. Demand Management
D. Request Fulfillment
2. Which one of the following is the correct list of functions?
A. Event Management, Incident Management, Problem Management, Access Management
B. Technical Management, Applications Management, Knowledge Management, Change Evaluation
C. Service Desk, Technical Management, Applications Management, IT Operations Management
D. Supplier Management, IT Security Management, Technical Management, Applications Management
3. Which of the following are Service Design processes?
i. Service Level Management
ii. Problem Management
iii. Service Portfolio Management
iv. Service Catalog Management
A. i, iii, and iv only
B. i and ii only
C. i and iv only
D. All of the above
4. Which one of the following is not a Service Strategy process?
A. Demand Management
B. Business Relationship Management
C. Financial Management
D. IT Security Management
5. Which of the following are Service Transition processes?
i. Change Management
ii. Release and Deployment Management
iii. Knowledge Management
iv. Service Asset and Configuration Management
A. iii only
B. i, ii, and iii only
C. ii, iii, and iv only
D. All of the above
Answers
1. A. This is a simple question with an obvious answer I hope! The Service Desk is, of course, a function.
2. C. If you got this wrong, review step 1 in Exercise 2-1.
3. C. Problem Management is a Service Operation process; Service Portfolio Management is a Service Strategy process.
4. D. IT Security Management is a Service Design process.
5. D. The other Service Transition processes are Transition Planning and Support, Service Validation and Testing, and Change Evaluation.