You are now starting your journey through the five stages of the IT Infrastructure Library (ITIL) lifecycle. Chapter 1 should, I hope, have laid a base of clear definitions and concepts from which you can confidently begin your travels with me. From Chapter 2 you should now have a road map to help you navigate the trip ahead.

The Purpose of Service Strategy

The ITIL books refer freely to purpose, objectives, and goals when it comes to lifecycle stages and processes. I wondered about the significant difference between these three words, so I checked my Concise Oxford Dictionary. It seems that another word for objectives is goals and that the purpose of something can be considered as its objectives! In management theory, I don’t doubt that these terms have subtly different meanings, but here I want to keep things simple.

Here are those purposes as far as the Service Strategy lifecycle stage is concerned:

•  To run the strategy processes   This means making sure that the processes are managed properly and that resources are used to best effect.

•  To define what the strategy is   If you haven’t defined the strategy, how can you possibly know what it is you’re trying to support?

•  To define the services and their customers   This is fundamental, isn’t it? Remember the definition of service: “. . . facilitating the outcomes your customers want to achieve.”

•  To define how value is created and delivered   Be clear what is meant by value and be clear about its ingredients.

•  To define the capability required to deliver the strategy   You’ll be looking at the composition of the service assets you’re managing.

•  To identify opportunities to provide services   You need to have a “marketing mind-set.” This means working closely with customers, understanding their needs, and proactively suggesting new and improved services.

Service Providers and Service Categories

Defining services and customers is a fundamental purpose of Service Strategy, and in Chapter 1 you were introduced not only to the crucial definition of service but also to the three defined types of service provider: Type I, an internal service provider that is embedded within the business unit it serves; Type II, an internal service provider whose services are shared among more than one business unit (also known as a shared service unit); and Type III, which provides services to external customers.

Services themselves are categorized as follows:

•  Core Services   These deliver the basic outcomes required by one or more customers. An example would be the spreadsheet functionality provided as part of office automation. The phrase “a means of facilitating the outcomes a customer wishes to achieve” (which I hope you’ll remember from the definition of service in Chapter 1) alludes to these core services.

•  Enabling Services   These are necessary for the core service to be delivered. An example could be the downloading and installation of updates regarding the communication, system, and application software supporting office automation. The phrase “without the ownership of specific costs and risks” (which follows the first part of the definition of service given in Chapter 1) alludes to these enabling services. Users and customers may be unaware of these enabling services.

•  Enhancing Services   These are supplements to core services to make them more attractive to customers. An example could be a service that enables the data in spreadsheets to be uploaded and reformatted into a relational database.

Value Creation

The creation of maximum value within the resource available comes from a perfect balance between utility and warranty, as shown in Figure 3-1.

Figure 3-1   Creation of service value

Utility can be viewed as the functionality of a service—the promise of all the good things the service is designed to provide. ITIL also describes utility as being fit for purpose, enabling a particular job either to be done better or even to be done at all.

However, that promise cannot be met and cannot be delivered unless there is matching warranty. Warranty is a mix of availability, capacity, continuity, and security. Where have you come across these processes recently? You met them in Exercise 2-1 where I grouped them together. Moreover, these are four of the processes you’ll encounter in Service Design.

ITIL describes warranty as being fit for use, and you’ll remember that ITIL describes utility as being fit for purpose (that’s helpful, isn’t it?). Make a note: utility is fit for purpose, and warranty is fit for use, not the other way round.

For a service to provide maximum value, there must be a perfect balance between utility and warranty; neither is more important than the other. For example, you could have a website that is rich in functionality, but if it keeps crashing or the capacity of your broadband connection is limited or there’s an occasional risk of power outages or every time you enter your password it is compromised, that limits its value; as a customer, you won’t be getting your “outcomes facilitated” as effectively as they could be. Such a service would be high in utility but low in warranty.

On the other hand, you could have a website that is always available, without any noticeable capacity constraints, resilient to all contingencies, and extremely secure, but if the functionality is of little or no use, the service would be valueless—high in warranty but low in utility.

In Service Strategy, you should be trying to understand as clearly as you can the utility and warranty aspects of any new or changed service. The utility aspect is often what you use to “sell” a new service; it’s the promise of good things. However, you must make adequate provision for the warranty aspects too; otherwise, you won’t be able to deliver on your promise. The challenge here is that warranty comprises a lot of cost, and, in business cases, there may be a temptation to play up utility and play down warranty. Don’t do that. You’ll get found out later in the lifecycle because at every lifecycle stage ITIL wants you to revisit utility and warranty to ensure that the service is still on course to deliver the expected value in the live world.

Assets

It’s all very well having great plans, theories, and management concepts, but if you’re going to achieve something worthwhile for your business and its customers, you need to have the wherewithal to do so. You must have the appropriate assets.

If you think of yourself as the service provider, you have your own assets. Your customers have their own assets too, of course. If what you deliver using your assets enhances your customer’s assets and you can demonstrate how that happens, your customer’s view of your importance to them will change. Your services to them will become of strategic importance; therefore, your IT service management practice becomes a strategic asset. It’s back to “facilitating your customer’s outcomes” again, isn’t it?

ITIL considers assets as falling under two broad headings, as covered in the following sections.

Resources

Resources are the sort of things that tend to be tangible, that are direct inputs for production, and that you can go out and acquire. The following are typical resources:

•  Financial capital   In other words, this means money. You might have a hoard of gold in an old oak chest, or you might have an obliging bank manager; I suppose you could even go out and rob a bank (although ITIL doesn’t recommend that!).

•  Infrastructure   This includes hardware, buildings, server rooms, uninterruptible power supplies, and so on. You can actually touch infrastructure; it’s very much tangible. You can go out and buy it.

•  Applications   Most applications these days are acquired from some external source. You purchase Microsoft Office from a licensed reseller, you have an enterprise resource planning (ERP) system from one of the usual suspects, or your own business-specific applications may be written and maintained for you by an external contractor.

•  Information   We live in the Information Age. The challenge is to sift out the information that is relevant from the mass of data that surrounds you. You don’t have to work hard to acquire information; the harder work is to handle what you get.

•  People   In terms of resources, I mean people as just “pairs of hands.” You can contact your local, friendly recruitment agency and get lots of people without too much difficulty.

Capabilities

In contrast to resources, capabilities are things you have to grow and develop. They are difficult if not impossible to go out and acquire off the shelf. Capabilities include such elements as the following:

•  Management   What does management look like? You can’t really see it, can you? You can see managers and supervisors behind their desks or walking around and you can identify and measure the outcomes of management, but you can’t go out and buy management as you would a bag of sugar. There’s no management shop you can visit and ask for “some medium-sized management, please, preferably in a relaxing green color.” Management is very much a fusion of the other capabilities.

•  Organization   This is like management; you can’t actually see it happening (although you can usually see the results of poor organization). Indeed, while you can have elegant organization charts and you can create RACI matrices, you still have to decide what sort of organization best suits your particular business. ITIL does not provide you with some sort of ideal organizational model that you can copy and use; however, it does provide valuable guidance.

•  Processes   Again, similar to the situation regarding organization, you have to design processes that suit your specific case. You should beware of just procuring an IT service management tool and applying it “out of the box.” The way that particular tool supports the ITIL processes may or may not be suitable to your particular requirement. It’s far better to design your processes first and then select the tool that best suits your needs.

•  Knowledge   This is information that you have analyzed; it is information that has been processed to meet your needs. Knowledge, of course, is power. You’ll be looking at the Knowledge Management process when you come to the Service Transition stage of the lifecycle.

•  People   But here, unlike people as a resource, I’m talking about trained, experienced, and motivated people. Yes, you can bring in interim managers and consultants to meet experience and skills gaps, but that should be a temporary expedient. There is no real substitute for having your own people in place to lead, manage, and perform your long-term activities.

I hope you agree that resources are more tangible in nature and usually much easier to acquire than capabilities, which are more abstract in nature and require specific development.

Service Strategy Processes

Of the five processes described next, Strategy Management is focused largely on the Service Strategy stage of the lifecycle. Regarding the others, Demand Management reappears in Service Design as an element of Capacity Management, while Service Portfolio Management, Financial Management, and Business Relationship Management are relevant throughout the lifecycle. Of course, all five processes are relevant to Continual Service Improvement.

Strategy Management

In essence, the purpose of the Strategy Management process (or the Strategy Management for IT Services process—its full title) is to ensure that a service strategy is defined, maintained, and managed. For convenience I’ll be referring to this process as just Strategy Management.

Key activities include the following:

•  Examining current external and internal environments; identifying strengths, weaknesses, opportunities, and threats; and looking for likely future developments

•  Developing and maintaining the “marketing mind-set” and defining market spaces and identifying opportunities for developing and offering services

•  Defining how the service provider can be differentiated from other service providers

•  Developing and maintaining a strategic plan

•  Running the Service Strategy stage of the service lifecycle

It should be noted that, for a service provider, what may be considered as the IT service management strategy is a subset of the service strategy which is itself a subset of the IT strategy.

The Strategy Management process is not part of the syllabus for the ITIL Foundation examination, but an awareness of its existence and its features is essential to a full and balanced understanding.

Service Portfolio Management

The Service Portfolio is one of the most useful of the service management tools. It provides a single, overall view of all services and is particularly valuable to the IT director (or whoever is considered to be “top management” in this context). It helps the service provider ensure that there is the correct mix of services in order to balance investment in IT with supporting the business—“facilitating the customer’s outcomes” again!

The Service Portfolio helps answer the following questions:

•  Which services should be provided and to whom?

•  How do those services help achieve the strategic objectives?

•  What value do those services give to the service provider?

•  What conditions should be applied to the provision of those services?

•  What is the level of investment in those services?

•  What changes are taking place in that investment?

•  How does a new service compare to the old service?

•  Which services should be retired from the live environment?

Figure 3-2 shows Service Portfolio Management diagrammatically.

Figure 3-2   Service Portfolio Management

Service Portfolio Management comprises two overlapping sections: Service Pipeline and Service Catalog. The Service Pipeline provides information on all services from the earliest conceptual point up to the moment when rollout to the live environment has been successfully accomplished. In contrast, the Service Catalog contains information on all services that are in the live environment plus those that are being prepared to be rolled out; those are the services that have been “chartered,” in other words, those for which resources have been allocated for building and testing.

The Service Catalog is visible to a wide readership (I’ll be covering it in greater detail in the “Service Design” section), whereas the Service Pipeline will have a more limited accessibility. The reason for this is that you want customers and users to be aware of the services that are live or will be going live so that they may make fullest use of them (have their outcomes facilitated). However, you don’t want all customers and users to see what’s earlier in the pipeline because those services may not be rolled out for some time, if at all, and when they are, they may then be different from the original concept.

I’m afraid ITIL is a little ambiguous when it comes to retired services. These services are certainly in the Service Portfolio because knowledge of them could be useful for reference purposes or the service could be resurrected at some point. However, the official diagram implies that retired services are to be found in the Service Catalog, whereas the Service Catalog stage described in Service Design excludes them (see Chapter 4). I suggest you work on the assumption that services are removed from the Service Catalog when they are retired.

In the next version of this figure, Figure 3-3, you see that services move from left to right as they proceed through their life from concept to retirement. To illustrate this, for example, imagine that v4.2 of a service might be the most recently retired version of a particular service, and it now sits with v4.1, v4.0, v3.0, and so on, in the retired part of the Service Portfolio. The current live version is v5.0 (which is in Service Operation), and the next upgrade is v5.1, which is in transition; both these version are visible in the Service Catalog. Further back up this channel is v5.2, which is the next major upgrade and is at the Service Design stage, while v6.0 is little more than a glimmer in someone’s eye and sits within conceptual services. These two developing versions are visible only in the Service Pipeline.

Figure 3-3   Service Portfolio Management showing illustrative service versions

Note also that Continual Service Improvement (CSI) sits in the Service Portfolio; CSI is never far away in ITIL!

In Figures 3-2 and 3-3, the number and size of the document shapes are meant to indicate approximately the relative amount of resources being used by each of the lifecycle stages. Those resources come from the IT director’s reservoir of resources. Specific resources are taken up and released as individual services move through their lives. Every resource that the IT director has is covered here, even research resources, because all resources should be linked in some way to a service even if that service may be little more than a vague concept.

Since the Service Portfolio covers all services, it is used throughout the service lifecycle, not just in Service Strategy. You will encounter it again.

Business Relationship Management

Business Relationship Management (BRM) is a comparatively new process in ITIL; it used to be mixed in with Service Level Management, but the management level at which BRM operates is more strategic in nature. The two processes are still closely related, as you will see in Service Design, but BRM is distinctively different.

The main purposes of BRM are twofold.

•  To establish and maintain a business relationship between the service provider and the customer

•  To identify customer needs and ensure that the service provider is able to meet those needs

To meet those purposes, BRM should do the following:

•  Understand, inform, and meet the customer’s perceived needs and communicate those needs within the service provider’s organization.

•  Identify technology trends that could impact the services to particular customers.

•  Identify changes in customers’ environments.

•  Mediate when there are conflicting requirements from different customers.

•  Establish formal complaints procedures (including escalation) for each customer. I always include a procedure for compliments too; you may be pleasantly surprised that you’ll get some!

That is the essence of BRM. However, there is a difference between BRM for internal service providers (Type I and Type II) and BRM for external providers (Type III). BRM for internal service providers involves senior managers within IT and their equivalents in the customer business units. For external service providers, BRM may be more specifically organized, with account managers being appointed to manage the relationship with their customers on a truly commercial basis.

You saw the definitions of service provider types in Chapter 1 and at the beginning of this chapter. If you can’t recall them, please take a quick look to refresh your memory; it’s useful to appreciate the difference between them.

Financial Management for IT Services

Unsurprisingly, the Financial Management for IT Services process is about money. Equally unsurprisingly, the subject of money is important throughout the service lifecycle, so this process is one that remains relevant at every stage, not just in Service Strategy. For convenience, I’ll be referring to this process as just “Financial Management.”

The purpose of Financial Management is to do the following:

•  To secure the funding necessary to design, develop, and deliver the IT services that are needed to support the business processes (in other words to support the Service Strategy)

•  To ensure that the service provider avoids promising services that cannot be afforded

•  To maintain a balance between cost and quality and between supply and demand

The three fundamental aspects of financial management have always been and, I suspect, always will be the following:

•  Budgeting   It is always risky to make predictions (especially about the future!), but when you are involved in budgeting, that is what you are trying to do. You need to have as clear a view as possible of what the next financial year’s requirements will be for your ongoing and prospective services. The budget arguments will, of course, be hugely strengthened because you will be able to link your requirements clearly to the agreed-on business processes you will be supporting. You will be exploring this further in the “Demand Management” section later in this chapter and in “Capacity Management” in Chapter 4.

•  Accounting   When the budget round is completed, the finance director has usually agreed to a number of “pots of gold,” otherwise called cost centers, which have their own unique codes and sums of money in them. As payments are authorized, they should quote the code of the appropriate cost center so that expenditure can be recorded against the budgetary provision. In simple terms, that is what accounting is about. If you are a service owner, for example, you would be interested in what is happening to your share of the money in the relevant cost centers.

•  Charging   The first point to make regarding charging is that it is not compulsory. Budgeting and accounting are compulsory, but many service providers, particularly Type I service providers (do you remember them from Chapter 1?), do not charge directly for their services to the rest of the business unit of which they are part. Of course, Type III service providers invariably charge for their services because they are commercial businesses. You may find yourself working in a Type I or Type II service provider where it has been decided that full charging is a good idea to inculcate cost consciousness and control expenditure. That would be a top management decision; ITIL (wisely) offers no guidance on what can be a vexing matter!

It should also always be remembered that all service providers have to abide by the financial policies and processes of the organization of which they are a part.

Let’s imagine that you have a superb service strategy and your Service Portfolio Management process is showing with excellent clarity how your services are facilitating the outcomes that the business processes require for the business strategy to be achieved. This won’t have happened by chance. With your marketing mind-set, your dedication to continual service improvement, and your first-class business relationship management, you will have been proposing a series of new, innovative services and service improvements. (Of course, you will—you’re in a utopian ITIL world!). Nevertheless, every significant new or changed service will have required a formal business case to be produced, considered, and approved.

A business case argues the merits and costs of a particular new or changed service and, as such, must cover the financial implications, particularly the expected return on investment (ROI). Hence, production of business cases is a crucial output from the Financial Management process. In simple terms, a business case is a decision support and planning tool that explains the purpose of a proposed initiative and its business impacts. A business case typically comprises five sections.

•  Introduction   The introduction explains what the drivers are for this change. Relevant background information should be provided. There should be a clear statement of the business objectives.

•  Methods and assumptions   The business may have mandated a particular approach to producing business cases, and it would be here that conformance to that mandate would be confirmed. If particular techniques, such as mathematical modeling, have been used, that should be recorded. Of crucial importance are the assumptions. These assumptions may cover such topics as expected future growth of the business, new technologies, the socioeconomic climate, and so on.

•  Business impacts   This is the heart of the business case and covers the expected ROI and the value of investment (VOI); ROI is the expected financial return, and VOI is the expected nonfinancial return, such as enhanced reputation. ROI may not always be positive; sometimes a change to a new service may be necessary for regulatory conformance, and then the VOI becomes overriding. The concept of utility and warranty underpins this business impact statement.

•  Risks and contingencies   This section addresses uncertainties that should have been identified during the analysis related to the previous methods and assumptions section. For each assessed risk, there should be consideration of the possible countermeasures.

•  Recommendations   The recommendations should be a set of conclusions derived from the logic of the case that has been presented. There should be clear proposals for future action, with these proposals in the form of a set of costed alternative options.

Demand Management

A critical part of effective Service Strategy is covered in Financial Management when you seek to ensure adequate funding for your services, maintaining a balance between cost and quality and avoiding making promises you can’t afford. A significant part of those costs arises from providing the necessary capacity in terms both of technical infrastructure and of support resources. The required capacity needs to be assessed during the Service Strategy lifecycle stage in order to calculate a realistic ROI. This of course brings you back to utility and warranty—capacity limitations may restrict your ability to deliver the promise you have made. The capacity you need to provide will, of course, depend on the demand for your services, which is why there is the need to address Demand Management during Service Strategy.

However, you won’t forget Demand Management as you move on through the lifecycle. In Service Design, you’ll revisit Capacity Management as a broader process in which Demand Management plays a vital role. In Service Transition, you will be testing and evaluating what it is you are creating to ensure that there are no unexpected capacity constraints, and in Service Operation, you will be gathering valuable management information to see how far the live operation actually matches your plans as well as detecting future trends.

In particular, Demand Management helps you understand two key aspects.

•  Identifying and analyzing patterns of business activity (PBAs)

•  Analyzing the usage made of services by different types of users and identifying and documenting user profiles

Many businesses have busy periods and quieter periods. For example, in drinks logistics there’s a lot more trucking going on during the run-up to Christmas and the New Year than during January. Other businesses show different patterns, perhaps on a weekly or monthly basis. Often there is a combination of patterns. Service Strategy requires you to ensure that the service provided is appropriate for the business it is supporting and that it includes these PBAs and, indeed, the different profiles of users who are involved. The service provider can then work with the customer to agree on the optimum balance to match the resources that can be afforded with the demand for the services that will use them.

The Demand Management process is not part of the syllabus for the ITIL Foundation examination, but an awareness of its existence and its features is essential to a full and balanced understanding of ITIL.

Roles in Service Strategy

When considering assets earlier in this chapter, I made the point that ITIL does not tell us how to organize ourselves specifically, but it does give valuable guidance. For each lifecycle stage, ITIL provides a set of roles with associated responsibilities that can serve as a useful checklist. Obviously we don’t have one separate person for each role (except, perhaps, in a huge organization), but it’s useful to go through those responsibilities and identify who has each one of them. You may then find some responsibilities that no one has been given specifically. As a result you may have a “black hole” down which things are disappearing. Alternatively, you might have two or more people with the same or very similar responsibilities. Are those people tending to work at cross-purposes or indulging in some sort of turf war? You may recall that I mentioned this in Chapter 1 in the section “Getting Organized the ITIL Way.”

There is a number of specific roles in Service Strategy, which I’ve shown in an organization chart in Figure 3-4. I’ve done that for illustrative purposes; this is not an organizational model for you to follow blindly!

Figure 3-4   Roles in Service Strategy

The generic responsibilities of Service Owner, Process Owner, and Process Manager are set out in Chapter 1. For the specific responsibilities of each of the roles shown in Figure 3-4, you will need to refer to the ITIL publications themselves.

Tools in Service Strategy

There is a tendency to think of technology in the context of IT service management as being mainly concerned with Service Desk. That aspect is, of course, important, but you should be aiming to have an integrated IT service management tool that covers the whole service lifecycle and that can interface easily with other, specialized tools.

Regarding Service Strategy, there are two particular areas where technology can be useful.

•  Service automation and analytics   This is relevant throughout the service lifecycle and enables greater consistency and higher throughput. It also enables the capture of accurate data for management purposes, much of which can be fed back to Service Strategy for better-informed strategic decisions. It would be a sensible IT policy to aim to maximize service automation as a powerful means for the better delivery of services that support the strategy.

•  Simulation   These tools enable possible service solutions to be modeled and the results analyzed, with the results forming part of a business case.

Chapter Review

Service Strategy is where the lifecycle of each service begins and is concerned with stating a clear mission, setting values, defining goals, and designating the approaches to be followed throughout the service lifecycle. If the strategy is wrong, it is highly likely that the service, when it eventually gets rolled out into the live environment, will not deliver the value it should and will probably be poor economically in performance. Worse, the effort put in during the Service Design and Service Transition lifecycle stages will have been largely wasted. You can end up delivering a service to the customer that, while it may perform to its specification, does not actually “facilitate the outcomes your customer wants to achieve.”

Quoting that extract from the definition of service reminds me that you must keep the principles and concepts of service management clear in your mind when you start exercising your management and planning skills. If you have only a fuzzy idea of what you mean by service, process, function, and so on, it is likely that your decisions affecting those aspects will also be fuzzy. Your decisions will be difficult for others to understand and to put into effect. Service Strategy adds to those clear definitions and concepts by introducing the idea of achieving value creation by establishing a balance between utility and warranty. It goes on to consider service assets and customer assets, how those assets are a combination of resources and capabilities, and that making the best use of (and even optimizing) your service assets will increase the value of your customers’ assets. All this serves to transform your business’s view of IT service management from it being an inescapable bureaucracy, outside of the core business (and often a candidate for injudicious outsourcing), to it being appreciated as a strategic asset.

In this lifecycle stage, the Strategy Management process works to ensure clarity, particularly regarding the definition of your services, and seeks to ensure the whole lifecycle stage is run effectively. Service Portfolio provides a complete picture of all services—from concept through live operation to retirement—and in so doing is relevant throughout the lifecycle. Service Portfolio Management shows “top management” the link between resources and the services and hence the value of those resources. Business Relationship Management ensures that there is the best possible communication between service provider and customer, building trust and mutual understanding. Meanwhile, Financial Management ensures the best possible stewardship of your assets and investments, with Demand Management helping the achievement of balance between supply and demand.

Finally, the justification for new or changed services is argued in the business case that, once agreed on, becomes the basis for the service specification that is passed from Service Strategy to Service Design.

Quick Review

Here are the key concepts and terms you’ve encountered in this chapter. Read through this list, and if anything seems unfamiliar or you can’t readily describe it, go back and read the relevant section again.

•  Purposes of Service Strategy

•  Value creation: utility and warranty

•  Assets: customer assets and service assets, including resources and capabilities

•  Process: Strategy Management

•  Process: Service Portfolio Management

•  Process: Business Relationship Management

•  Process: Financial Management

•  Process: Demand Management

•  Tools: automation and simulation

Further Reading

The ITIL Foundation course takes a simplified view of the complex area of Service Strategy but without losing its essence. For those who want to pursue this stage of the lifecycle in greater depth, I strongly recommend attending a Service Strategy ITIL lifecycle course or the Service Offerings and Agreements ITIL capability course. Moreover, those who have a master’s degree in business administration, or who are studying for that qualification, or indeed are involved in the development of business studies as an academic discipline, should find rewarding a thorough engagement with the main ITIL Service Strategy publication.

Questions

Here are seven further questions that are typical examples of what you’ll encounter in the foundation exam. This time all seven are simple multiple choice; that won’t be the same for the remaining question sets!

1.  Which one of the following is not a stage in the service lifecycle?

A.  Service Transition

B.  Service Strategy

C.  Service Optimization

D.  Service Design

2.  When considering value creation through services, which of the following statements is correct?

A.  The value of a service should be measured only in financial terms.

B.  The customer’s perception of value is an important factor.

C.  The preferences of the service provider are crucial to value perception.

D.  Facilitating the outcomes of the service provider determines value.

3.  Which one of the following should be delivered to customers by IT services?

A.  Resources

B.  Capabilities

C.  Value

D.  Knowledge

4.  What is the meaning of warranty in the context of services?

A.  The service is fit for purpose.

B.  The service performance is guaranteed by the service provider.

C.  Any service failures are fixed without charge for an agreed-on period.

D.  The service is fit for use.

5.  Which one of the following should always be found in the service catalog?

A.  The complete Service Pipeline stage

B.  The details of all live services

C.  A list of all the resources and capabilities of the service provider

D.  Management and organizational information

6.  Which one of the following is a main purpose of Business Relationship Management?

A.  Ensuring all contractual service targets are met

B.  Liaising with suppliers

C.  Understanding the needs of the service provider’s customers

D.  Defining service warranty

7.  Which one of the following stakeholders is the most appropriate to define the value of a service?

A.  The IT steering group

B.  The finance department

C.  The owner of the strategy management process

D.  The customer

Answers

1.  C. If you didn’t choose this answer, which one did you choose and why? Here’s a supplementary question: what lifecycle stages are not mentioned in the question? The answer is Continual Service Improvement and Service Operation, of course.

2.  B. It’s not up to the service provider to define value here, and while financial aspects are important, value also can be expressed in nonfinancial terms (for example, in reputational terms).

3.  C. A major constant theme in ITIL is that services create value.

4.  D. Option A is the meaning of utility, of course. Options B and C are nothing to do with utility and warranty in service management.

5.  B. Only the last element of the Service Pipeline (services being prepared to go live) appears in the Service Catalog.

6.  C. I trust that choosing this answer wasn’t difficult.

7.  D. Yes, it’s the customer’s perception that’s important. I’m sure you won’t forget that.