Chapter 5

Are We All Agreed? Service Design Part 1: The Relationship Management Processes

In This Chapter

Knowing how the service design stage of the lifecycle works

Seeing how to manage service levels

Cataloguing information about live services

Managing third-party suppliers

Some years ago on a Saturday night, my wife and I invited friends to dinner. It was the first time I had cooked for them. When my friend arrived, he introduced his wife and said, ‘I did remember to tell you she’s a vegetarian, didn’t I?’ The answer was no. Panic! After a quick bit of rethinking, my meat dish separated itself into both a vegetarian and non-vegetarian version. The evening went well and we’re all still very good friends to this day. The moral of the story? Make sure you establish the requirements before you start.

In Chapter 3 I introduce you to the service lifecycle, of which service design is one part. The service design stage includes eight processes – a lot to cover in one chapter, so I’ve split the content between this chapter and Chapter 6. This chapter covers service level management (SLM), service catalogue management and supplier management – I like to call these the relationship management processes (this is my description, not an official ITIL term). This chapter also covers the design coordination process. Chapter 6 covers the other four processes: availability management, capacity management, IT service continuity management and information security management. The chapters are designed for you to read separately, but to get the whole picture you may want to read both in order.

Before you dive in, here’s the essence of the service design processes: find out what the customer wants, design a service to meet those requirements, talk to the customer about the design, and get agreement.

Understanding the Purpose of the Service Design Lifecycle Stage

How do you know whether you’re doing decent job? How do you know whether your organisation is providing the IT services required by the business? You won’t know unless you’ve agreed up front what the customer wants from you and how it will measure your success. You will think about these things in the service design stage.

The main purpose of the ITIL service design stage of the lifecycle is the design of new or changed services for introduction into the live environment.

The service design stage of the lifecycle is where you take an idea for a new service or a change to an existing service, and put meat on the bones. From the high-level business requirements that you establish in the service strategy stage (which I explain in Chapter 4), you now create plans, designs and estimates of resources that help you understand what creating the service or change involves – if you choose to go ahead. So this is the stage that covers the gathering and analysis of the service requirements, and the design of the service. You must gather the detailed requirements of the service, check that they’re achievable, and then design the service to meet the requirements.

Understanding Some Basic Principles

Before you launch into service design, you need a grounding in some basic principles of this stage of the service lifecycle.

Keeping in mind the four Ps of service design

You must consider four areas when designing service management:

People: Ensure you have the right people in place with the right skills and training.

Processes: The service management processes! Make sure they’re properly designed and suit your needs.

Products/technology: The IT services themselves along with any tools or underpinning technology. Again, ensure they’re appropriate.

Partners/suppliers: Ensure you have the right third-party suppliers in place that are able to help you deliver and support the service.

Knowing the five aspects of service design

I could have titled this section ‘The scope of the service design stage’. What sort of things do you design in this stage? Clearly, you design the service, but when doing so you must also identify the impacts on other areas that may be affected by the design. ITIL refers to these areas as the five aspects of service design. Here they are:

Service solutions: Designing the new or changed services. You gather and agree all the functional requirements and estimate the resources and capabilities you need to develop and operate the service.

Service management systems and tools: Any service management tools you use, for example a service desk call-logging tool. You must establish a set of requirements and acquire or develop the tools to meet these requirements. ITIL gives special mention here to the service portfolio (which I cover in Chapter 4), from which you extract the high-level business requirements for new services.

Technology architecture and management systems: The architecture, tools and systems that must be in place to support the design of the infrastructure, data and environments.

Processes: Designing the service management processes. Designing and implementing these processes can be time-consuming and complex. I include more advice on implementation in Chapter 10.

Measurement systems, methods and metrics: Not the actual monitoring tools themselves, though you use them to gather much of your measurement data – the emphasis here is on designing a structure to collate the right measurements and metrics that provide the necessary visibility and ability to control the service and the service management processes.

Creating a service design package

A service design package (SDP) is a package of documents that define all aspects of the design and requirements. This package is one of the main outputs of the service design stage of the service lifecycle. You produce a SDP for each new service, major change or service removal. The SDP details all aspects of the service through the subsequent stages of the service lifecycle.

The following is a brief overview of what a typical SDP includes:

Business and service requirements

Service level requirements (SLRs) or service level agreements (SLAs) (more on these in the following section)

The design of the preferred solution

Organisational readiness assessment

Service lifecycle plan for the introduction of the service

Service acceptance criteria, including criteria for sign-off of the service by the business

Managing Service Levels: Service Level Management

You don’t know whether you’ve hit the target if you don’t know where the target is. Everyone needs standards, otherwise you’re fighting in the dark.

What do you think the service level management process does? Yep – it manages the service levels. I like to summarise the service level management process in the following way. Service level management:

Defines, agrees and documents service levels

Monitors, reports and reviews service levels

Improves service levels

The purpose of the service level management process is to ensure that all current and planned IT services are delivered to agreed, achievable targets.

Your service level management process must maintain a close relationship with your business relationship management process. Many of the triggers of the service level management activities can come from business relationship management. You will find the business relationship management process described in Chapter 4.

Defining some service level management terms

Oh, how ITIL loves jargon. Never fear; in this section I explain the terms you come across in the service level management process.

Service level agreements

According to the ITIL books, ‘An SLA is an agreement between an IT service provider and a customer. The SLA describes the IT service, documents service level targets, and specifies the responsibilities of the IT service provider and the customer’.

The SLA is the main agreement. Without it the customer doesn’t know what it’s getting and the provider doesn’t know what to provide. The SLA should be in clear, unambiguous business language and cover aspects such as availability, capacity, security and IT service continuity. Gone are the days when the IT department deliberately included vague targets so that it could tweak the reports to make things look good, or when you could inherit SLAs and continue with them without any understanding of whether they were achievable or measurable.

To negotiate, agree and set up SLAs with the customer is a time-consuming and sometimes challenging task. So why bother? Table 5-1 helps you see the merits of these agreements.

Table 5-1 The Benefits of SLAs

With SLAs . . .	Without SLAs . . .
You set the expectations of both parties	You don’t know whether you’re any good at providing the service
You can measure the service	You may either over- or under-achieve
You have clear targets to achieve	You can never be right

© Crown copyright 2011. Reproduced under licence from the Cabinet Office.

You must make sure that all those who help provide the services understand the part they play in delivering them. That means putting underpinning agreements in place. These are operational level agreements (OLAs) and underpinning contracts (UCs) (see the next two sections).

Operational level agreements

The ITIL books say ‘An OLA is an agreement between an IT service provider and another part of the same organisation’, for example between teams within the IT department. An OLA supports the IT service provider’s delivery of IT services (in accordance with the SLA) to customers. And now you’re among friends, so you can talk techie!

The IT department of a manufacturing organisation has a total of 20 SLAs in place for the various services it provides to its internal customers. The network team leader has commented to the service level manager that his department finds it difficult to understand what level of service it has to provide to which customers at what time. The service level manager suggests they sit down and draft an OLA. They review all the SLAs and identify how each service target relates to the network service. They note where a common level of service is needed across many customers and where special levels of service are required for particular customers. They now create one simplified set of service targets and document them in the OLA. Now the network team has a single set of targets to meet that allows it to meet the targets in the SLA.

Underpinning contracts

According to the ITIL books ‘A underpinning contract (UC) is a contract between an IT service provider and a third party supplier. The third party supplier provides goods or services that support delivery of an IT service to a customer. The UC defines targets and the responsibilities required to meet agreed service level targets in an SLA’ (see the earlier section ‘Service level agreements’).

No difference exists between a contract and an underpinning contract. The term just reminds you that the contract must underpin the targets in your SLA.

You negotiate and manage the contracts you have with your suppliers by using the supplier management process (see ‘Getting Friendly with Third-party Suppliers: Supplier Management’ later in this chapter). The service level manager ensures that the supplier manager is clear about the requirements of the part of the service to be provided by the supplier, and between the service level manager and supplier manager ensure that the contract underpins the SLA with the customer.

Service level requirements

Service level requirements (SLRs) are the documented requirements of the customer prior to the SLA being agreed. Here is the starting point for negotiation. For a major development project, the SLR is the starting point for the design of the service. As the project goes through the service transition stage (see Chapter 7), testing provides confidence that the requested requirement can be fulfilled. At this stage, you create a draft SLA. As the service is deployed, the significance of the SLR fades and the SLA becomes the operative document. The SLA is signed as agreed by both parties.

SLA frameworks

Ask yourself how many business units and how many IT services you have. For example, say you have 10 business units and 50 IT services. If every customer uses every service then potentially you may have 500 SLAs. Hands up anyone who’d like to manage 500 SLAs! Now, I can already hear you shouting at me, ‘But not all my customers use the same services.’ So hopefully you can simplify the number of SLAs you have. Here come some suggestions:

Service-based SLA: An SLA for one service that describes the targets for many customers.

Customer-based SLA: An SLA for one customer that describes the targets for many services.

In addition to these two, you can also have multi-level agreements:

Corporate level: An agreement covering the generic issues appropriate to all customers, for example: service levels for common services such as the email service; how to contact the service desk; how to request changes.

Customer level: An agreement covering issues relevant to a particular customer or business unit, regardless of the service being used.

Service level: An agreement covering issues relevant to a specific service for a specific customer.

I’ve now given you a choice of five agreement types to choose from. Which is best? As ever, the answer is ‘it depends’. You probably find that a combination of types works for you, but you have to sit down and plan the best combination.

Customer satisfaction

Customer satisfaction may seem an odd thing to cover in a section on jargon. But do you know what the term means? Of course, customer satisfaction means keeping the customer satisfied. However, often the IT department thinks it’s doing a good job, and the opposite is true. For example, you look at the service level reports prior to the monthly service review meeting with a customer. You read the results and think, ‘Wow, we’ve achieved all the service targets. I bet the customer will be really happy.’ But when you enter the meeting room, the customer tells you what an appalling month it has had!

The provider and the customer can have a different perception of the same achievements for many reasons:

The SLA doesn’t meet the customer’s needs.

The customer hasn’t communicated the agreed service levels to the users, and the users have complained.

The SLA targets can’t be measured accurately.

The SLA targets don’t reflect the relative criticality of the services or the critical business periods.

The customer or provider has misinterpreted the requirements.

The SLA isn’t underpinned by appropriate OLAs or contracts.

The moral of the story is that you must measure customer satisfaction as well as achievement of the service targets. Often the service desk sends out surveys to users. Service level management should collate and review this feedback to form a better overall view of the quality of the service. Customer satisfaction is a prime concern of the business relationship management process. Service level management and business relationship management must work closely together. Business relationship management is covered in Chapter 4.

Service improvement plan

In the words of the ITIL books ‘A service improvement plan (SIP) is a formal plan to implement improvements to a process or IT service’.

That’s as good and clear as definitions go – for a change. Don’t get over-excited: a SIP is very simple. It’s just a plan, or a small project, to investigate the factors that lead to a poor quality of service and to suggest actions to improve the service or service management processes.

Looking at the activities of service level management

The following sections explore the main activities of the service level management process.

Determining, documenting and agreeing requirements for new services (creating SLRs) and producing SLAs

This activity involves a discussion with the customer of the service to discover its SLRs. (I explain SLRs in the earlier section ‘Defining some service level management terms’.)

Here’s how the activity works:

1. The service level manager gains an understanding of the business activities performed by the customer. Then the manager can communicate the importance of the service to others in the service provider organisation. The requirements are documented.

2. The service level manager returns to the IT provider to establish whether the requirements are achievable. This triggers other service management processes, especially availability management, capacity management, IT service continuity management and information security management. (Chapter 6 has the low-down on these.) These processes ensure that the specific aspects of the service requirements are fully assessed and the impacts of meeting the requirements are understood.

3. The service level manager negotiates with the customer regarding the level of service that is achievable and affordable. This can take several goes. Inevitably, the customer modifies its requirements during the negotiations, and you have to return to the technical staff to double-check.

I can’t emphasise enough the importance of getting the steps right. Once agreed, these are the service levels you must stick to, and on which your success as a service provider will be measured. Also, by using so few words, I may have made this activity sound easy. It isn’t! You may be left tearing your hair out or mumbling in a corner after the tenth round of negotiations and fifteenth draft of the SLA. You must persevere. Once you start providing the services in accordance with the SLA, there will be laughter and happiness all around.

Reviewing and revising SLAs, service scope and underpinning agreements

This set of activities relates to the previous set, and is often part of the same process. Whenever you receive a new set of requirements, you must check that they are achievable, and what it will cost to achieve them. This involves negotiating and agreeing the necessary underpinning agreements. These agreements are usually the OLAs and UCs. (More on these in the earlier section ‘Defining some service level management terms’.) You use the supplier management process (which I cover in the later section ‘Getting Friendly with Third-party Suppliers: Supplier Management’) to negotiate and set up the UCs. The service level manager ensures that the contracts underpin the SLA that has been agreed with the customer.

The service level manager negotiates and sets up the OLAs. They represent a commitment from other parts of the service provider organisation to fulfil their parts of the bargain. So for example, if the server team believes it can fix all priority-2 incidents in less than two hours, it should be willing to sign an OLA confirming this fact.

Monitoring service performance against the SLA and producing service reports

Unfortunately, once you have agreed and signed your SLAs, you can’t throw them in a drawer, shut it and forget about them. You must measure and report on your service achievements. How often do you monitor your service levels? As often as you committed to do in your SLA. The service operation people are monitoring your services and components all the time. You must ensure that they collect and collate the appropriate information that you need to go into your service reports.

You have to produce and circulate reports regularly in line with what you agreed in the SLA. When reporting to customers, keep things simple: don’t flood customers with unnecessary information and data. Also, don’t get too techie – unless customers ask for the complex stuff.

Exception reports are a good idea. As the name suggests, you report on exceptions only – so SLA breaches or service outages. This prevents you from printing page after page of data that simply tells the customer things are okay. Another popular report goes under many names: RAG chart (red, amber, green) or traffic light chart. ITIL calls this a SLAM chart – service level agreement monitoring chart. Have a look at the example in Figure 5-1.

Conducting service reviews and instigating improvements within an overall service improvement plan

Service reviews are regular reviews between the service provider and the customer. Aim to hold these meetings at least quarterly, though I know many organisations that hold them monthly. These aren’t reviews of the SLA – not an opportunity to renegotiate the SLA – but an opportunity to review service achievements for the last period. Of course, service achievement can be both good and bad.

Send out your reports a few days before the meeting so that the customer has time to review them. You don’t want to waste time in the meeting reading reports together. How dull. Instead, spend the time discussing any outages or breaches in the last period and reviewing any points either party needs to be aware of in the forthcoming period.

Service reviews are great for identifying opportunities for improvement. The customer may be looking at the SLAM chart (see the previous section) and say, ‘Looks like you’ve had a lot of amber lights recently – wouldn’t you like to do something about it?’ The amber lights indicate a number of outages in the last period that the IT department should investigate. The appropriate response is for the service level manager to set up a SIP. To do this, he probably calls on the help of his very good friend the continual service improvement (CSI) manager, and they work together to set up the plan to investigate the outages and recommend improvements.

Collating, measuring and improving customer satisfaction

You must get a qualitative feel for the service you’re providing to the customer. Customer satisfaction surveys are a good way of doing this.

Be careful. What do you do when walking down the street and someone grabs you and asks you to complete a survey? Similarly, you may be sitting at home watching your favourite TV programme, and the phone rings and the caller asks you to complete a survey – it won’t take long! What’s your reaction? Most people have a natural aversion to surveys, so you take that into account when surveying your users and customers. Keep surveys simple and don’t ask users to complete them too often.

The service desk often helps with surveys. It can send out email surveys after an incident, or ask users their opinions of the service while on the phone, and then pass this to service level management to be included in reports and service reviews.

Developing contacts and relationships, recording and managing complaints and compliments

Hopefully, if all the activities I describe in the preceding section are performed well then the natural consequence is a good relationship with your customers. However, natural happenstance isn’t enough: you have to make building a positive relationship an objective of the process. The necessary negotiations and service reviews go much better if you build a relationship based on openness and trust.

This activity also includes dealing with complaints and compliments. The service level management process acts as the escalation point for service issues from either party. The customer should contact the service level manager with any complaints or issues. Similarly, if the service provider can anticipate possible service breaches or issues, these should be escalated to the service level manager, who can discuss them with the customer. The business relationship management process is concerned with the customer’s overall satisfaction with all the service received, so make sure you understand who does what and that the lines of communication don’t get crossed (business relationship management is covered in Chapter 4).

Keeping Information about the Live Services: Service Catalogue Management

What does service catalogue management entail? Managing the service catalogue. What’s a service catalogue? Basically, a catalogue of your services.

The purpose of the service catalogue management process is to provide and maintain a single source of consistent information on all operational services and those being prepared to be run operationally, and to ensure that it’s widely available to those who are authorised to access it.

Defining the service catalogue

In ITIL-speak, the service catalogue is a database or structured document with information about all live IT services, including those available for deployment. The service catalogue is the only part of the service portfolio (the complete set of services managed by a service provider) published to customers, and you use it to support the sale and delivery of IT services (there’s more about the service portfolio in Chapter 4). The service catalogue includes information about deliverables, prices, contact points, ordering and request processes.

At its most basic, a service catalogue is a simply list of your live IT services plus those being prepared to go live. It includes a summary of the main attributes of each service and an overview of the agreed service levels. But the service catalogue can be much, much more than a list of services. Often, complex software applications are used to allow staff to drill down and view details of each service.

Figure 5-2 gives you an idea of what a service catalogue may look like.

Based on ITIL® material. Reproduced under licence from The Cabinet Office.

The information in your service catalogue can be presented in many ways; these are often called views. A service catalogue view restricts the information you show to specific groups of people. ITIL provides the following examples:

Two-view service catalogue:

• Business service catalogue: The business service catalogue is the customer view of the service catalogue. This is the only bit you show to the customers. It contains the details of all the IT services delivered to the customers, along with the relationships to business units and business processes that rely on the IT services.

• Technical service catalogue: The technical service catalogue is the technical view of the service catalogue. This is the bit you keep to show your technical staff. It contains the details of all the IT services delivered to the customers, along with the relationships to the supporting services, shared services and other components and assets.

Three-view service catalogue:

• Wholesale customer view: Shows the details of services available to wholesale customers, along with the relationships to the customers the services support.

• Retail customer view: Shows the details of services available to retail customers, along with the relationships to the customers the services support.

• Supporting services view: This view is similar to the technical service catalogue described above and provides details of the supporting services required to deliver the services displayed in the wholesale and retail customer views.

Looking at the activities of service catalogue management

The service catalogue management process is straightforward and consists of those activities needed to ensure that the service catalogue is accurate and reflects the current details, status, interfaces and dependencies of all services that are being run, or being prepared to run, in the live environment.

In order to achieve this you:

Agree and document a service definition.

Produce and maintain the service catalogue and its content, ensuring consistency with the service portfolio.

Interface with all parts of the business and the IT function who help supply information to the service catalogue or rely on information from the service catalogue.

Getting Friendly with Third-party Suppliers: Supplier Management

You can’t do everything yourself. Sometimes it makes sense to get someone else to do it. However, whenever you get some else to do something for you, you hope they’ll do it to an acceptable standard.

This is where you turn the tables. Service management is all about providing a good service to your customers. However, sometimes you’re the customer, so what do you expect from your suppliers? If you believe in the philosophy of customer service, you expect to receive a similar quality of service from your suppliers as you give to your customers. But, as with all things to do with service management, you need a clear understanding of, and agreement about, what you expect from your suppliers.

Suppose you’re planning to build an extension on your house. You choose not to do it yourself but to pay a building organisation to do it. Do you tell it what to do? Well, you give it the plans and tell it what the final extension should be like, and you set a standard for the quality of the workmanship. You also agree a price. Do you now stand over the craftsman every minute of the day, telling everyone how to do their job? I think not. But you check every now and again and look for indicators that everything is going to plan.

The purposes of the supplier management process are to obtain value for money from suppliers, and to provide a seamless quality of IT service to the business by ensuring that all contracts and agreements with suppliers support the needs of the business, and that all suppliers meet their contractual commitments.

As ITIL definitions go, this one is fairly straightforward:

Value for money: Commercial companies are in business to make money. If you ask a supplier to provide a service for you, then I’m sure you expect to pay for it, but how much are you prepared to pay? The important thing is to get value for money.

Seamless quality of IT service: Your customers aren’t interested in seeing the joins between the bits that you do and the bits you get someone else to do. One of the most frustrating things you may hear an assistant say when you phone a call centre is, ‘I’m sorry, we can’t deliver your goods. Our supplier has let us down.’ My reaction to this is, ‘I don’t care; that’s your problem. Get it sorted.’ Or is it just me? You must ensure that the bits that your suppliers provide are integrated into the end-to-end service and are able to contribute to the level of service you have agreed with your customer.

Defining some supplier management terms

Jargon be gone! Here’s some demystification to help you get to grips with the supplier management process:

Supplier: According to the ITIL publications, a supplier is ‘A third party (external to your organisation) responsible for supplying goods or services required to deliver IT services. Examples of suppliers include commodity hardware and software vendors, network and telecom providers, and outsourcing organisations’.

Supplier and contract management information system (SCMIS): A set of tools, data and information about your suppliers and the contracts you have with them. This useful repository of information and data allows you to manage your suppliers and the relationship you have with them. Your supplier management policy drives the actual detail of what you keep in the SCMIS, which is usually:

• All supplier details

• Details of contracts

• Details of the services and products provided by each supplier

• A categorisation of each supplier and its products, such as ‘commodity’, ‘service’ or ‘partner’

You also come across the word contract or underpinning contract (UC) in the supplier management process; I cover this in the earlier section on service level management.

Looking at the activities of supplier management

Read through the following sections to gain an understanding of the supplier management process.

Supplier strategy and policy

Having a policy for when you use a supplier and when you do a task yourself is sensible. Your policy can be as simple as: all application development is done by a supplier; all wide-area networks are done by a supplier; everything else we do ourselves.

Here are some other areas of strategy and policy that you should address:

Should we have a preferred supplier list?

Who is responsible for managing suppliers?

How do we ensure that all contracts are legally sound?

Definition of new supplier and contract requirements

The service design stage includes designing the service and producing a requirements specification. (You can read more about this in Chapter 12.) This must be authorised before you search for a supplier to provide the service for you. Supplier management often works with service level management to gain a clear understanding of what is needed from a supplier.

Evaluating new suppliers and contracts

Welcome to the whole world of procurement. You may use other words in your organisation, but I’m referring to the process of identifying potential suppliers, getting their interest, and then evaluating and selecting the appropriate suppliers. This is often called the invitation to tender (ITT) process. Your organisation may already have its own (sometimes long and complex) method of procurement for all purchasing, not just IT. In fact, some industry sectors impose regulations on how to procure.

You must have a consistent way of fairly assessing all potential new suppliers and services to ensure you select the ones that can best provide the service you need and best match your organisation.

This stage also includes the contract negotiations with the prospective suppliers. This, of course, must be done with care and honesty to ensure that both parties enter into a successful and mutually beneficial relationship.

Establishing new suppliers and contracts

When engaging new suppliers, ensure you assess and record any risks. Carry out checks on the supplier’s past performance and its financial status. Once the contracts are signed, you add the supplier to your SCMIS.

Depending on the type of supplier, you may perform other activities in the service transition stage (see Chapter 7) to ensure that the supplier’s service is integrated into your IT service; for example, network suppliers connecting their equipment to yours; an infrastructure outsourcer transferring your data to its systems. In some cases, the supplier may need regular access to your building, in which case you must familiarise them with your ways of working.

Supplier, contract and performance management

Regularly measure and report on the performance of your suppliers to provide factual evidence that they’re providing the service as agreed, and to enable you to spot any issues in time to do something about them. Hold regular performance reviews (meetings) with your suppliers, similar to those you hold with your customers, to review:

Service performance against targets

Any incidents or problems

Any changes or issues expected in the forthcoming period

Any improvement plans

Contract renewal or termination

All good things come to an end, and so might your contracts. Contracts are rarely open-ended, but may need renewing. The SCMIS tells you the end dates or renewal dates for all your contracts, and you can use the information to help you plan what to do when the contract runs out. The obvious choices are renew or terminate. However, you can also take the opportunity to renegotiate the contract to take into account any business changes.

Supplier categorisation, and maintenance of the SCMIS

Not all suppliers are equal. Some absorb more management time and effort than others. The clever bit is knowing which you handle in what way.

For example, if a supplier provides commodity products such as paper or printer cartridges, you probably don’t have an intimate relationship with a single supplier and phone each other every day. More likely, you maintain a list of preferred suppliers and choose whoever has the best discount on the day you want to place the order. On the other hand, if you have outsourced a critical part of your infrastructure upon which most of your services rely, then you likely have a much closer relationship with the supplier.

Here are some typical categories for your suppliers:

Strategic: The sort of thing negotiated and managed by senior managers in your organisation, like major network provision that’s integrated with your services. Needs frequent communication.

Tactical: Usually managed by middle managers in the organisation. Includes support contracts for hardware and software, and needs regular communication and performance reviews.

Operational: Products and services like Internet access and non-critical website hosting. This needs regular contact, but less often than for tactical suppliers.

Commodity: Generally low-value stuff like paper or printer cartridges. Contact is as and when required.

Design Coordination

There’s quite a lot going on in the service design stage – it makes common sense to coordinate it.

If you have a programme or project office in your organisation, you may be familiar with the role it has in the high-level planning and coordination of projects. The design coordination process performs similar activities for your design projects. Service design activities are often carried out as projects, or are part of other projects.

The purpose of the design coordination process is to ensure that the goals and objectives of the service design stage are met, by providing and maintaining a single point of coordination and control for all activities and processes within this stage of the service lifecycle.

Here’s a brief look at the activities of the design coordination process. The activities of the design coordination process are divided into two groups: those applied to all design activities, and those applied to a specific design:

Overall activities:

• Defining and maintaining policies, standards and guidelines, and ensuring they are used

• Planning the resources needed for service design activities

• Managing design risks and issues

• Improving service design

Activities performed for each design:

• Planning, coordinating and monitoring individual designs; these are three separate activities, all aimed at ensuring the smooth management of a project to create the design of a new or changed service

• Ensuring the production of the SDP from documents and inputs provided by the application and technical teams involved in the design activities

Identifying Service Design Roles

Each service management process should have a process owner and a process manager. I explain these two roles in Chapter 2. For the relationship management processes, the relevant process manager roles are:

Service level manager

Service catalogue manager

Supplier manager

Design coordination manager

Each role is responsible for the activities described in the appropriate section of this chapter.

In addition to the process-related roles, you may want to consider some general service design roles. These are associated with design activities such as the gathering and analysis of requirements and the subsequent production of designs. These roles are:

IT planner

IT designer/architect