Chapter 10
Introduction to the Service Design Lifecycle Stage

THE FOLLOWING ITIL INTERMEDIATE EXAM OBJECTIVES ARE DISCUSSED IN THIS CHAPTER:

  • ✓  The main purpose, goals, and objectives of service design
  • ✓  The scope of service design
  • ✓  Service design’s value to the business
  • ✓  The context of service design and the service lifecycle
  • ✓  Service design inputs and outputs and the contents and use of the service design package
  • ✓  The contents and use of service acceptance criteria

 This part of the book covers how service design takes the outputs from service strategy, the preceding stage of the service lifecycle, and uses them to ensure that the solution designs that are produced are consistent with the overall IT service provider strategy. We have seen, in the earlier chapters of this book, how service strategy sets the objectives; service design is about providing the services that are required to deliver those objectives. Service design is also concerned with redesigning existing services and retiring services that are no longer needed. This first chapter provides an introduction to this lifecycle stage; we consider the core concepts of service design in terms of its purpose, objectives, and scope and its relationship to the other ITIL lifecycle stages.

The learning objective for this chapter is to achieve a full understanding of service design terms and core concepts. We start by looking at the purpose of service design, its objectives and scope, and how it delivers value to the business.

Service design is a critically important stage of the service lifecycle. It is in design that the intentions behind the service strategy start to be made reality. A poor service design will fail to deliver the strategy, could prevent a worthwhile return on investment, and could potentially damage the performance and reputation of the business. This stage is often rushed, however, in an attempt to meet project deadlines; such a course of action is foolish because it remains true that time spent in design saves time spent in rework later.

The Purpose of Service Design

The purpose of the service design stage of the lifecycle is to design IT services, with the necessary supporting IT practices, processes, and policies, to realize the service provider’s strategy. It is important to understand this point—design is not just about the technical design; it also considers the way it will be used and the processes required. Design should also include thinking about how the service will be transitioned; it should facilitate the introduction of the service into the supported environment in such a way as to ensure quality service delivery, customer satisfaction, and cost-effective service provision. So it is the job of design to make the strategy a practical reality. Importantly, design must consider how the service will work.

The Goals and Objectives of Service Design

Let’s start by considering the goals and objectives of service design. Service design has to design services to satisfy business objectives and align with business needs. This includes consideration of quality, compliance, risk, and security requirements, ensuring the delivery of more effective and efficient IT and business solutions by coordinating all design activities for IT services. Ensuring consistency of service and business focus in the design is a key goal.

Service design activities can be periodic, or they can be triggered by a specific business need or event. (We call these exception-based activities.) In an ideal world, service design would design IT services so effectively that little or no improvement during their lifecycle would be required. However, it is only when services are actually being used in the live environment that we can really understand what is required of them. The use of the services will also change over time. It is essential, therefore, for service design to embed continual improvement in all its activities. This ensures that the solutions and designs become even more effective over time. This will enable changing trends in the business that could provide improvement opportunities to be identified and acted upon.

Additional goals and objectives of service design are as follows:

  • Ensuring that the services that are designed are adaptable to future requirements so they can be easily expanded or developed to meet changing requirements
  • Aiming to produce a design that reduces, minimizes, or constrains the long-term costs of provision because a service that is too expensive to run has no future
  • Designing an efficient and effective service management system, including the processes required for the design, transition, operation, and improvement of high-quality IT services
  • Providing the supporting tools, systems, and information, especially the service portfolio, to manage services through their lifecycle
  • Identifying and managing risks so that they can be removed or mitigated before the services go live

The final set of goals and objectives of service design are as follows:

  • Designing the measurement methods and metrics for assessing the effectiveness and efficiency of the design processes and their deliverables. Design must consider how the effectiveness of a service could be measured and ensure that the service is designed so that these metrics can be gathered.
  • Producing and maintaining all the IT plans, processes, policies, architectures, frameworks, and documents needed for the design of quality IT solutions that will meet current and future agreed business needs.
  • Assisting in the development of policies and standards in all areas of design and planning of the IT services and processes. By receiving and acting on feedback on design processes from other areas and incorporating this feedback into the processes in the future, design ensures continual improvement of these processes.
  • Developing skills and capability within IT by moving strategy and design activities into operational tasks, making effective and efficient use of all IT service resources.
  • Contributing to the improvement of the overall quality of IT service within the imposed design constraints. It reduces the need for reworking and enhancing services once they have been implemented in the live environment.

The Scope of Service Design

The scope of ITIL service design includes providing guidance for the design of appropriate and innovative IT services to meet current and future agreed business requirements. The core guidance for this lifecycle stage describes the principles of service design and looks at identifying, defining, and aligning the IT solution with the business requirement. It also introduces the concept of the service design package and looks at selecting the appropriate service design model. We shall look at the contents and use of the service design package later in this chapter, and consider service design models in more depth in Chapter 11, “Service Design Principles.”

It is a key principle of ITIL service design that the initial service design should always be driven by factors such as functional requirements, the requirements within service level agreements (SLAs), the business benefits, and the overall design constraints. The service design Intermediate course syllabus covers the methods, practices, and tools to achieve excellence in service design. It discusses the fundamentals of the design processes and attends to what are called the “five aspects of service design.”

The Five Aspects of Service Design

These are the five aspects of service design:

  • The design of the actual solution itself
  • The service management system and tools that will be required to manage the service
  • The management and technology architectures that the service will use
  • The processes needed to support the service in operation
  • The measurement systems, methods, and metrics that will be required

These shall be examined later in Chapter 11, “Service Design Principles.”

Also included within the scope of service design are the service design processes:

  • Design coordination
  • Service catalog management
  • Service level management
  • Availability management
  • Capacity management
  • IT service continuity management
  • Information security management
  • Supplier management

These processes are described in detail later in the book. It should be noted that all of these processes, other than design coordination, are also active throughout the other stages of the service lifecycle and processes in other stages of the service lifecycle will impact service design. All the lifecycle processes should be linked closely together to ensure the successful management, design, support, and maintenance of the services, the IT infrastructure, the environment, the applications, and the data. The interfaces between processes need to be clearly defined when designing a service or improving or implementing a process.

In Figure 10.1, you can see the complete service design stage. It starts with a set of new or changed business requirements and ends with the development of a service solution designed to meet the documented needs of the business. This service solution, together with its service design package, is then passed to service transition to evaluate, build, test, and deploy the new or changed service or to retire the service if this is the change required. On completion of these transition activities, control is transferred to the service operation stage of the service lifecycle.

Image described by surrounding text.

Figure 10.1 The scope of service design

Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.

The overall scope of service design and the five aspects of design are illustrated in Figure 10.2, within the context of the IT service provider’s relationship to the business. The diagram shows how IT and the business interact through the provision of service and how the work of service design is part of the complete service lifecycle.

Diagram shows the relationship between business services, SLAs, service management processes, service knowledge management system, IT service provider, support teams, suppliers et cetera.

Figure 10.2 The scope of service design and the five aspects

Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.

The Value Service Design Delivers to the Business

Adopting the best practice recommended by ITIL delivers significant business benefits. Good service design ensures both the quality and the cost-effectiveness of the service. Both aspects need to be delivered if the service is to be useful to the business. Good service design using a standard, consistent approach delivers a number of benefits, which we will consider in turn:

  • A reduced total cost of ownership (TCO). The design will consider the costs of various design options and choose one that delivers what is required, without unnecessary expenditure. In addition, because the design fits the business requirement, there will not be a large volume of changes to try to align it more effectively with the business requirement. Aspects such as the availability and capacity requirements for the service must be considered during the design stage to reduce incidents (and the resulting support costs) when the service is operational.
  • Improved quality of service. Services that are well designed and meet the required outcomes of the customer will deliver the quality of service that the business needs.
  • Improved consistency of service. Designing services within the corporate strategy, architectures, and constraints will ensure that a consistent level of service is delivered.
  • Easier implementation of new or changed services. Well-designed services are easier to transition.
  • Improved service alignment. By involving service design from the beginning, we can ensure that the new or changed service is designed to match the business requirement and will be able to support the required service levels.
  • Improved service performance. The service will have been designed to meet the specific performance criteria, incorporating capacity, availability, and IT service continuity requirements into the design.
  • Improved IT governance. This will be as a result of ensuring that the necessary controls are built into the design.
  • Improved effectiveness of service management and IT processes. The design of processes is one of the five aspects of service design; when processes are considered as part of design, it is to be expected that they will be designed to deliver both quality and cost effectiveness.
  • Improved information and decision-making. The design includes ensuring that the required measurements and metrics will be produced, enabling the service provider to be confident that they possess accurate information on which to base decisions. These measurements will also form the basis for assessing the service and identifying opportunities for continual improvement of both services and service management throughout the service lifecycle.
  • Improved alignment with customer values and strategies. If an organization has a policy of promoting concepts such as green IT or a strategy of using cloud technologies, service design will ensure that the design of the new or changed service is aligned with these values and strategies.

Service design ensures that IT services focus on supporting business processes and goals. This includes the following:

  • Prioritizing IT activities based on business impact and urgency so that critical business processes and services receive the most attention
  • Increasing business productivity by ensuring that IT processes are efficient and effective
  • Supporting corporate governance requirements with appropriate IT governance and controls, ensuring compliance with regulatory and legislative requirements
  • Exploiting the IT infrastructure and providing innovative solutions to create competitive advantage
  • Improving service quality, customer satisfaction, and user perception
  • Ensuring that all IT and information assets are appropriately protected

The Context of Service Design and the Service Lifecycle

Service design needs to be considered within the context of the whole service lifecycle. Each area of the lifecycle addresses a particular set of challenges that need to be addressed for successful service management, and each stage has an impact on all of the others.

Diagram shows the stages of service lifecycle which include service strategy at the core, service design, transition, and operation at the second level, and continual service improvement at the outer level.

Figure 10.3 The ITIL service lifecycle

Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.

Service Strategy Service strategy is at the core of the service lifecycle. It is the role of strategy to understand the organizational objectives and customer needs. People, processes, and products should support the strategy. ITIL service strategy asks why something is to be done before thinking of how. It helps service providers to set objectives; to set expectations of performance serving customers and markets; and to identify, select, and prioritize opportunities. Service strategy ensures that providers understand and can handle the costs and risks associated with their service portfolios.

The complete list of service strategy processes is as follows: strategy management for IT services, service portfolio management, financial management for IT services, demand management, and business relationship management.

Service Design Service design, the subject of Part 2 of this book, turns strategic ideas into deliverables. The design must always consider the strategy to ensure that services are designed with the business objectives in mind. Design considers the whole IT organization and how it will deliver and support the services, turning the service strategy into a plan for delivering the business objectives. Remember, design includes changes to existing services and retiring those services no longer required.

The complete list of service design processes is as follows: design coordination, service catalog management, service level management, availability management, capacity management, IT service continuity management, information security management, and supplier management. These processes ensure that both the utility and the warranty of the new or changed service is considered in design, covering the continuity of the service, its achievement of service levels, and conformance to security standards and regulations.

Service Transition Service transition provides guidance for developing and improving capabilities for introducing new and changed services into supported environments. The value of a service is identified in strategy, and the service is designed to deliver that value. Service transition ensures that the value is realized by enabling the necessary changes to take place without unacceptable risks to existing services. Service transition enables the implementation of new services, and the modification of existing services, to ensure that the services provided deliver the service strategy of achieving the business objectives and that the benefits of the service design are fully realized. Service transition also introduces the service knowledge management system, which ensures that knowledge is stored and made available to all stages of the service lifecycle, making sure lessons are learned and decisions are backed with factual data, leading to improved efficiency and effectiveness over time.

The complete list of service transition processes is as follows: transition planning and support, change management, service asset and configuration management, release and deployment management, service validation and testing, change evaluation, and knowledge management. Each process has a role to play to ensure that beneficial changes can take place and, as a consequence, the service can be introduced and will work as transitioned.

Service Operation Service operation describes best practice for managing services in supported environments. It includes guidance on achieving effectiveness, efficiency, stability, and security in the delivery and support of services to ensure value for the customer, the users, and the service provider. Without this, the services would not deliver the value required and the achievement of business objectives would become difficult or impossible.

The service operation stage is therefore critical to delivering the design and, in doing so, achieving the service strategy. Service operation provides detailed guidance for delivering the service within the agreed service levels by tackling issues both proactively, through problem management, and reactively, through incident management. It provides those delivering the service with guidance for managing the availability of services, controlling demand, optimizing capacity utilization, scheduling of operations, and avoiding or resolving service incidents and managing problems. It includes advice on shared services, utility computing, web services, and mobile commerce. By delivering the services to the agreed levels, service operation enables the business to use the services to achieve its business objectives.

The complete list of service operation processes is as follows: event management, incident management, request fulfilment, problem management, and access management. We shall be considering each of these in the service operation section of this book, in the chapters covering service operation processes. Each process has a role to play to ensure the delivery of services within the agreed service levels. Service operation also describes the four service operation functions: the service desk, technical management, IT operations management, and application management. Each function is responsible for managing its own area of delivery across all stages of the lifecycle.

Continual Service Improvement The final stage of the lifecycle is continual service improvement. CSI ensures that the service provider continues to provide value to customers by making sure the strategy, transition, and operation of the services is under constant review. Feedback from any stage of the service lifecycle can be used to identify improvement opportunities for any other stage of the lifecycle. It ensures that opportunities for improvement are recognized, evaluated, and implemented when justified. These may include improvements in the quality of the service or the capabilities of the service provider. It may be developing ways of doing things better or doing them to the same level but more efficiently. Improvements may be major or small and incremental. It enables every new operation to incorporate lessons from previous operations.

CSI ensures that feedback from every lifecycle stage is captured, analyzed, and acted upon. The CSI approach to improvement is based on establishing a baseline and checking to see whether the improvement actions have been effective. It uses the Plan-Do-Check-Act (PDCA) cycle, together with service measurement, demonstrating value with metrics and conducting maturity assessments. The seven-step improvement process provides a framework for these approaches.

In addition to these long-term improvement initiatives, there are the short-term ongoing improvements; these are the improvements made to working practices within the processes, functions, and technologies that underpin service design. They are generally smaller improvements that are implemented without any change to the fundamental nature of a process or technology. Examples include tuning, workload balancing, personnel redeployment, and training.

Service Design Inputs and Outputs

The main inputs to service design are requirements for new or changed services. The main output of service design is the service design package, which includes all of the information needed to manage the entire lifecycle of a new or changed service. We shall look at the service design package later in this chapter, but first we examine the particular inputs to service design and outputs from design for each lifecycle stage.

Strategy Inputs and Outputs

The inputs from strategy into service design are as follows:

  • Vision and mission
  • Service portfolio
  • Policies
  • Strategies and strategic plans
  • Priorities
  • Service charters, including service packages and details of utility and warranty
  • Financial information and budgets
  • Documented patterns of business activity and user profiles
  • Service models

Strategy provides the vision and mission about what is to be done. The decision regarding what services should form the portfolio is made in the strategy stage of the lifecycle, along with other strategies and plans.

Strategy provides the utility and warranty requirements to design for the new service. It formulates the service packages and service charters (these are covered in detail in the service strategy course). Strategy documents the patterns of business activity and the different user profiles and decides upon the service models. Finally, strategy is in control of the money—design can start its work only when strategy has decided to fund it.

Let’s now consider the reverse flow, the outputs from design into strategy:

  • Input to business cases and the service portfolio
  • Service design packages
  • Updated service models
  • Service portfolio updates, including the service catalog
  • Financial estimates and reports
  • Design-related knowledge and information in the service knowledge management system (SKMS)
  • Designs for service strategy processes and procedures

Design provides important information that strategy uses in the service portfolio and to draw up business cases. The major output from design is the service design package, and this is an input to the strategy phase as well as to other lifecycle stages. Other outputs to strategy from design include updates to the service models, service catalog, and portfolio. Design will produce new process designs for strategy processes, will update the service knowledge management system, and produce financial reports and estimates to feed back into financial management.

Transition Inputs and Outputs

Following the activities of service design, a number of outputs are passed to the next stage, that of transition:

  • Service catalog details
  • Service design packages, including the following:
    • Details of utility and warranty
    • Acceptance criteria
    • Service models
    • Designs and interface specifications
    • Transition plans
    • Operation plans and procedures
    • Communication and training plans
    • User and support guides
  • RFCs to transition or deploy new or changed services
  • Input to change evaluation and CAB meetings
  • Designs for service transition processes and procedures
  • SLAs, OLAs, and underpinning contracts

The major output is the service design package (SDP), which includes the details of the new or changed service and plans for its transition and operation. We will look at the SDP in more detail shortly. Design will also raise the requests for change to kick off the transition and deployment. In addition, design will provide input to the evaluation process so that it is clear how the service is expected to behave and what benefits it is expected to deliver. Design may also provide information to the change advisory board to help in their deliberations. Finally, the SLAs, OLAs, and underpinning contracts that were drawn up as part of the design process of service level management are passed to transition. It will be the job of transition to ensure that the new or changed service meets the agreed service levels by the time it is accepted into operation.

Service design takes a number of outputs from transition. These are mostly in the form of feedback and potential improvements for the next service design:

  • Service catalog updates
  • Feedback on all aspects of service design and service design packages
  • Input and feedback to transition plans
  • Response to requests for change (RFCs)
  • Knowledge and information in the SKMS (including the CMS)
  • Design errors identified in transition for redesign
  • Evaluation reports

Transition will provide feedback on every aspect of service design and on the adequacy of the service design package. Transition will also respond to the proposed transition plan it received from design, with any suggested amendments. Reports from the evaluation stage will be fed back to design, along with details of any design errors that came to light during transition and require redesign.

In addition, transition will respond to the requests for change raised by service design and will update the service knowledge management system and configuration management system as the service is deployed.

Operation Inputs and Outputs

Service design provides the following outputs to the operation stage:

  • Service catalog
  • Service design package, including these:
    • Details of utility and warranty
    • Operations plans and procedures
    • Recovery procedures
    • Knowledge and information in the SKMS
    • Which services are considered vital business functions
    • Hardware and software maintenance requirements
    • Designs for service operation processes and procedures
    • SLAs, OLAs, and underpinning contracts
    • Security policies

As you may notice, some of these were also outputs to other stages, particularly the service design package. Here, though, the SDP content that is passed to operations is particularly concerned with the operation of the new or changed service, containing details of utility and warranty that should be delivered in operations along with plans, procedures, processes, and security policies for operations to carry out. Again, we can see that the SKMS is updated. The utility and warranty requirements are backed up with the hardware and software maintenance requirements and details of the SLA to be delivered together with the underpinning OLAs and contracts that will be needed to meet the SLA successfully. Finally, details of vital business functions are passed to operations to assist in the assessment of the impact of incidents and their prioritization.

The service operation stage of the lifecycle provides the following inputs into service design:

  • Operational requirements
  • Actual performance information
  • RFCs to resolve operational issues
  • Historical incident and problem records

The operational requirements to be incorporated into the design and the actual performance information ensure that design understands how the service is performing. Any operational issues that arise could result in an RFC to have a design change, and the provision of historical incident and problem records will show design the issues to be avoided in the new design.

CSI Inputs and Outputs

Design provides the following outputs to the continual service improvement lifecycle stage:

  • Service catalog
  • Service design packages, including details of utility and warranty
  • Knowledge and information in the SKMS
  • Achievements against metrics, KPIs, and CSFs
  • Design of services, measurements, processes, infrastructure, and systems
  • Design for the seven-step improvement process and procedures
  • Improvement opportunities logged in the CSI register

CSI will need the service catalog, the SKMS, and the service design packages with the details of the utility and warranty requirements to identify which services are failing to meet their requirements and need to be improved. The achievements of the different service design processes against key performance indicators will identify which processes need improvement. CSI will also need to understand the design of the services, processes, and so on to identify where improvements can be made. Service design is responsible for the design of the seven-step improvement process and procedures.

Service design will also suggest improvements, which will be logged in the CSI register.

The outputs from continual service improvement to design are as follows:

  • Results of customer and user satisfaction surveys
  • Input to design requirements
  • Data required for metrics, KPIs, and CSFs
  • Service reports
  • Feedback on service design packages
  • RFCs for implementing improvements

The results of customer and user satisfaction surveys, indicating how well the design meets their requirements, will show where it should be improved. Feedback on the service design packages will be used by design to improve future SDPs. CSI will raise the RFCs required to implement design improvements. Finally, service reports and other data required for metrics, KPIs, and CSFs are provided by CSI to service design.

Table 10.1 summarizes service design inputs and outputs by lifecycle stage.

Table 10.1 Summary of service design inputs and outputs by lifecycle stage

Lifecycle stage Service design inputs (from the lifecycle stage in the first column) Service design outputs (to the lifecycle stage in the first column)
Service strategy Vision and mission
Service portfolio
Policies
Strategies and strategic plans
Priorities
Service charters, including service packages and details of utility and warranty
Financial information and budgets
Documented patterns of business activity and user profiles
Service models
Input to business cases and the service portfolio
Service design packages
Updated service models
Service portfolio updates, including updates to the service catalog
Financial estimates and reports
Design-related knowledge and information in the SKMS
Designs for service strategy processes and procedures
Service transition Service catalog updates
Feedback on all aspects of service design and service design packages
Input and feedback on transition plans
Response to requests for change (RFCs)
Knowledge and information in the SKMS (including the CMS)
Design errors identified in transition for redesign
Evaluation reports
Service catalog Service design packages, including:
  • Details of utility and warranty
  • Acceptance criteria
  • Service models
  • Designs and interface specifications
  • Transition plans
  • Operation plans and procedures
  • RFCs to transition or deploy new or changed services
  • Input to change evaluation and CAB meetings
  • Designs for service transition processes and procedures
  • SLAs, OLAs, and underpinning contracts
Service operation Operational requirements
Actual performance information
RFCs to resolve operational issues
Historical incident and problem records
Service catalog Service design package, including:
  • Details of utility and warranty
  • Operations plans and procedures
  • Recovery procedures
  • Knowledge and information in the SKMS
  • Vital business functions
  • HW/SW maintenance requirements
  • Designs for service operation processes and procedures
  • SLAs, OLAs, and underpinning contracts
  • Security policies
Continual service improvement Results of customer and user satisfaction surveys
Input to design requirements
Data required for metrics, KPIs, and CSFs
Service reports
Feedback on service design packages
RFCs for implementing improvements
Service catalog
Service design packages, including details of utility and warranty
Knowledge and information in the SKMS
Achievements against metrics, KPIs, and CSFs
Design of services, measurements, processes, infrastructure, and systems
Design for the seven-step
improvement process and procedures Improvement opportunities logged in the CSI register

Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.

The Contents and Use of the Service Design Package

The service design package is the major output of service design. This is a collection of documents defining all aspects of the service. It could include technical design documents, service level agreements, acceptance criteria, business requirements, testing plans, and so on. Without the service design package pulling all these documents together into one place, there would be no single source of accurate information regarding the service.

The service design package should be produced during the design stage, for each new service, each major change to a service, the removal of a service, or even for changes to the service design package itself. It is passed from service design to service transition and from transition to operations. It details all aspects of the service and its requirements through all of the subsequent stages of its lifecycle.

The Contents and Use of Service Acceptance Criteria

The service acceptance criteria is a set of criteria used to ensure that the service meets its expected functionality and quality and that the service provider is ready to deliver the new service once it has been deployed. It can be used as a checklist to ensure that nothing has been forgotten. Table 10.2 shows typical service acceptance criteria.

Table 10.2 Typical service acceptance criteria

Criteria Responsibility
Have the “go-live” date and the guarantee period been agreed with all concerned parties, together with final acceptance criteria? Change, service level
Have the deployment project and schedule been documented, agreed, and made public to all affected personnel? Change, incident
Have the service level agreement (SLA) and service level requirements (SLRs) been reviewed, revised, and agreed with all concerned parties? Service level
Has the service been entered/updated in the service catalog/service portfolio within the configuration management system (CMS) and appropriate relationships established for all supporting components? Service level, configuration
Have all customers and other stakeholders been identified and recorded in the CMS? Service level, business relationship
Have all operational risks associated with running the new service been assessed and mitigation actions completed where appropriate? Business continuity, availability
Have contingency and fail-over measures been successfully tested and added to the overall resilience test schedule? Business continuity, availability
Can all SLA/SLR targets be monitored, measured, reported, and reviewed, including availability and performance? Service level, availability
Have all users been identified/approved and the appropriate accounts created for them? Account management
Can all workload characteristics, performance, and capacity targets be measured and incorporated into capacity plans? Capacity
Have all operational processes, schedules, and procedures been agreed, tested, documented, and accepted (e.g., site documentation, backups, housekeeping, archiving, retention)? Operations, business continuity
Have all batch jobs and printing requirements been agreed, tested, documented, and accepted? Operations
Have all test plans been completed successfully? Test manager
Have all security checks and tests been completed successfully? Security compliance
Are appropriate monitoring and measurement tools and procedures in place to monitor the new service, together with an out-of-hours support rota? Systems management
Have all ongoing operational workloads and costs been identified and approved? Operations, IT finance
Are all service and component operational costs understood and incorporated into financial processes and the cost model? IT finance
Have incident and problem categories and processes been reviewed and revised for the new service, together with any known errors and deficiencies? Incident, problem reporting
Have all new suppliers been identified and their associated contracts drawn up accordingly? Contract and supplier management
Have all support arrangements been reviewed and revised—SLAs, SLRs, operational level agreements (OLAs)—and contracts agreed, with documentation accepted by all teams (including suppliers, support teams, supplier management, development teams, and application support)? Project manager
Has appropriate technical support documentation been provided and accepted by incident, problem, and all IT support teams? Incident, problem
Have all requests for change and release records been authorized and updated? Change
Have all service, SLA, SLR, OLA, and contract details, together with all applications and infrastructure component details, been entered on the CMS? Project management, support teams configuration
Have appropriate software licenses been purchased or reallocated licenses used? Configuration
Have any new hardware components been recorded in the CMS? Configuration
Have all new software components been lodged in the definitive media library (DML) with details recorded in the CMS? Configuration
Have all maintenance and upgrade plans been agreed, together with release policies, frequencies, and mechanisms? Release and deployment
Have all users been trained, and has user documentation been accepted and supplied to all users? Project manager
Are all relationships, interfaces, and dependencies with all other internal and external systems and services documented, agreed, and supported? Project manager
Have appropriate business managers signed off on acceptance of new service? Project manager

Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.

Exam Essentials

Understand the purpose of service design The purpose of service design is to design IT services with the necessary supporting IT practices, processes, and policies to realize the service provider’s strategy. Design is not just about the technical design; it also considers the way it will be used and the processes required.

Understand that services must be designed to be adaptable to future requirements. Services should be designed so that they are able to be easily expanded or developed to meet changing requirements.

Be able to list and explain the five aspects of service design. The five aspects of service design are the design of service solutions, management information systems and tools, architectures, processes, and measurements.

Understand how good design delivers financial and other benefits to the business. When the design fits the business requirement and is adaptable to changing requirements, the need to completely redesign the service is avoided, thus minimizing the total cost of ownership.

Summary

This chapter covered the purpose, goals, objectives, and scope of service design and how this lifecycle stage delivers value to the organization. We looked at service design within the context of the service lifecycle. We also discussed service design inputs and outputs and the contents and use of the service design package and the service acceptance criteria.

Review Questions

You can find the answers to the review questions in the appendix.

  1. Which of the following is NOT a purpose of service design?

    1. To evaluate the financial impact of new or changed strategies on the service provider
    2. To ensure quality service delivery
    3. To ensure customer satisfaction
    4. To ensure cost-effective service provision
  2. Which of the following are goals of service design?

    1. To ensure that services are adaptable and expandable to meet future requirements
    2. To consider the total cost of ownership so that long-term costs are controlled
    3. To develop the required processes and tools for designing, transitioning, operating, and improving services during their life span
    4. To manage risks effectively, ensuring that the design is resilient and secure and meets current and future requirements
      1. 1, 2, and 4 only
      2. 1, 2, and 3 only
      3. All of the above
      4. 1, 3, and 4 only
  3. Which of the following is NOT one of the five aspects of service design?

    1. Designing service solutions
    2. Risk management
    3. Management and technology architectures
    4. Measurement systems, methods, and metrics
  4. What is being defined here? “Document(s) defining all aspects of an IT service and its requirements through each stage of its lifecycle. A _______________ is produced for each new IT service, major change, or IT service retirement.”

    1. Statement of requirements (SoR)
    2. Service acceptance criteria (SAC)
    3. Service level requirement (SLR)
    4. Service design package (SDP)
  5. Which of the following is NOT a possible service acceptance criteria?

    1. All SLA/SLR targets can be monitored, measured, and reported.
    2. Contingency measures have been successfully tested.
    3. A postimplementation review has been held, and the lessons learned have been documented.
    4. The service has been entered/updated in the service catalog/service portfolio.
  6. Which of the following is NOT a service design process?

    1. Service catalog management
    2. Service level management
    3. Service portfolio management
    4. Information security management
  7. Which of the following is NOT a benefit of effective service design?

    1. Services that are easier to change when circumstances change
    2. A reduced total cost of ownership (TCO)
    3. Improved IT governance
    4. Improved design of business processes
  8. Which of the following are inputs into service design from service strategy?

    1. Vision and mission
    2. Service portfolio
    3. Policies
    4. Strategies and strategic plans
    5. Service design packages
    6. Updated service models
    7. Priorities
    8. Service charters
      1. All of the above
      2. 1, 2, 3, and 4 only
      3. 1, 3, 4, 5, and 7 only
      4. 1, 2, 3, 4, 7, and 8 only
  9. Which stage of the lifecycle provides the following outputs, and to which stage are they an input?

    1. Feedback on all aspects of service design and service design packages
    2. Input and feedback on transition plans
    3. Response to requests for change (RFCs)
    4. Knowledge and information in the SKMS (including the CMS)
      1. Outputs from strategy into transition
      2. Outputs from transition into design
      3. Outputs from design into transition
      4. Outputs from operation into design
  10. Which of the following are valid inclusions in a service design package?

    1. Technical design documents
    2. Service level agreements
    3. Change schedule
    4. Acceptance criteria
    5. Business requirements
    6. Testing plans
    7. The CMS
      1. All of the above
      2. 1, 2, 3, 5, and 6 only
      3. 1, 2, 4, 5, and 6 only
      4. 1, 2, 4, and 5 only
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset