Service Design BOOK TEL v0_7.

indb 5
Appendix A: The
service design
package A
08/07/2011 17:24
Service Design BOOK TEL v0_7.indb 6 08/07/2011 17:24
 | 303

Appendix A: The service design package

A ‘service design package’ (SDP) should be to service transition and details all aspects of the
produced during the design stage, for each new service and its requirements through all of the
service, major change to a service or removal of a subsequent stages of its lifecycle. The contents of
service or changes to the ‘service design package’ the SDP are shown in Table A.1.
itself. This pack is then passed from service design

Table A.1 Contents of the service design package

Sub-category Description of what is in the SDP

Requirements Business requirements The initial agreed and documented business requirements
Service applicability This defines how and where the service would be used. This could
reference business, customer and user requirements for internal
services
Service contacts The business contacts, customer contacts and other stakeholders in
the service
Service design Service functional The changed functionality (utility) of the new or changed service,
requirements including its planned outcomes and deliverables, in a formally agreed
statement of requirements (SoR)
Service level The service level requirements (SLR), representing the desired warranty
requirements of the service for a new or changed service. Once specific service level
targets have been agreed and validated, the revised or new service
level agreement (SLA), including service and quality targets
Service and Management requirements to manage the new or changed service
operational and its components, including all supporting services and agreements,
management control, operation, monitoring, measuring and reporting
requirements
Service design and The design, transition and subsequent implementation and operation
topology of the service solution and its supporting components, including:
■■ The service definition, service model, packaging and service options
■■ All service components and infrastructure (including hardware,
software, networks, environments, data, applications, technology,
tools, documentation), including version numbers and
relationships, preferably within the configuration management
system (CMS)
■■ All user, business, service, component, transition, support and
operational documentation
■■ Processes, procedures, measurements, metrics and reports
■■ Supporting products, services, agreements and suppliers

Organizational Organizational ‘Organizational readiness assessment’ report and plan, including:

readiness readiness assessment business benefit, financial assessment, technical assessment, resource
assessment assessment and organizational assessment, together with details of all
new skills, competences, capabilities required of the service provider
organization, its suppliers, supporting services and contracts
Table continues

Service Design BOOK TEL v0_7.indb 7 08/07/2011 17:24

 304 | Appendix A: The service design package

Table A.1 continued

Sub-category Description of what is in the SDP

Service Service programme An overall programme or plan covering all stages of the lifecycle of
lifecycle plan the service, including the timescales and phasing, for the transition,
operation and subsequent improvement of the new service including:
■■ Management, coordination and integration with any other
projects, or new or changed activities, services or processes
■■ Management of risks and issues
■■ Scope, objectives and components of the service
■■ Skills, competences, roles and responsibilities
■■ Processes required
■■ Interfaces and dependencies with other services
■■ Management of teams, resources, tools, technology, budgets,
facilities required
■■ Management of suppliers and contracts
■■ Progress reports, reviews and revision of the programme and plans
■■ Communication plans and training plans
■■ Timescales, deliverables, targets and quality targets for each stage

Service transition plan Overall transition strategy, objectives, policy, risk assessment and plans
including:
■■ Build policy, plans and requirements, including service and
component build plans, specifications, control and environments,
technology, tools, processes, methods and mechanisms, including
all platforms
■■ Testing policy, plans and requirements, including test
environments, technology, tools, processes, methods and
mechanisms
■■ Testing must include:
●● Functional testing
●● Component testing, including all suppliers, contracts and
externally provided supporting products and services
●● User acceptance and usability testing
●● System compatibility and integration testing
●● Service and component performance and capacity testing
●● Resilience and continuity testing
●● Failure, alarm and event categorization, processing and testing
●● Service and component, security and integrity testing
●● Logistics, release and distribution testing
●● Management testing, including control, monitoring, measuring
and reporting, together with backup, recovery and all batch
scheduling and processing

Service Design BOOK TEL v0_7.indb 8 08/07/2011 17:24

 Appendix A: The service design package | 305

Sub-category Description of what is in the SDP

Service transition plan ■■ Deployment policy, release policy, plans and requirements,
continued including logistics, deployment, staging, deployment environments,
cultural change, organizational change, technology, tools,
processes, approach, methods and mechanisms, including
all platforms, knowledge, skill and competence transfer and
development, supplier and contract transition, data migration and
conversion

Service operational Overall operational strategy, objectives, policy, risk assessment and
acceptance plan plans including:
■■ Interface and dependency management and planning
■■ Events, reports, service issues, including all changes, releases,
resolved incidents, problems and known errors, included within
the service; and any errors, issues or non-conformances within the
new service
■■ Final service acceptance

Service acceptance Development and use of service acceptance criteria for progression
criteria through each stage of the service lifecycle, including:
■■ All environments
■■ Guarantee and pilot criteria and periods

Service Design BOOK TEL v0_7.indb 9 08/07/2011 17:24

Service Design BOOK TEL v0_7.indb 10 08/07/2011 17:24
 Appendix B: Service
acceptance criteria

Service Design BOOK TEL v0_7.indb 11

B
08/07/2011 17:24
Service Design BOOK TEL v0_7.indb 12 08/07/2011 17:24
 | 309

Appendix B: Service acceptance criteria

The service acceptance criteria (SAC) comprise a the service provider is ready to deliver the new
set of criteria used to ensure that a service meets service once it has been deployed. Table B.1 gives
its expected functionality and quality and that examples of such criteria.

Table B.1 Examples of service acceptance criteria

Criteria Responsibility
Have the ‘go-live’ date and the guarantee period been agreed with all concerned parties, Change, service level
together with final acceptance criteria?
Have the deployment project and schedule been documented, agreed and made public to all Change, incident
affected personnel?
Has the service level agreement (SLA)/requirements (SLR) been reviewed, revised and agreed Service level
with all concerned parties?
Has the service been entered/updated in the service catalogue/service portfolio within the Service level,
configuration management system (CMS) and appropriate relationships established for all configuration
supporting components?
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 Business continuity,
mitigation actions completed where appropriate? availability
Have contingency and fail-over measures been successfully tested and added to the overall Business continuity,
resilience test schedule? availability
Can all SLA/SLR targets be monitored, measured, reported and reviewed, including availability Service level,
and performance? availability
Have all users been identified/approved and their appropriate accounts created for them? Account management
Can all workload characteristics, performance and capacity targets be measured and Capacity
incorporated into capacity plans?
Have all operational processes, schedules and procedures been agreed, tested, documented Operations, business
and accepted (e.g. site documentation, backups, housekeeping, archiving, retention)? continuity
Have all batch jobs and printing requirements been agreed, tested, documented and Operations
accepted?
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 Systems management
new service, together with an out-of-hours support rota?
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 IT finance
processes and the cost model?
Have incident and problem categories and processes been reviewed and revised for the new Incident, problem
service, together with any known errors and deficiencies? reporting
Table continues

Service Design BOOK TEL v0_7.indb 13 08/07/2011 17:24

 310 | Appendix B: Service acceptance criteria

Table B.1 continued

Criteria Responsibility
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 Project manager
agreements (OLAs) – and contracts agreed, with documentation accepted by all teams
(including suppliers, support teams, supplier management, development teams and
application support)?
Has appropriate technical support documentation been provided and accepted by incident, Incident, problem
problem and all IT support teams?
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 Project management,
infrastructure component details, been entered on the CMS? support teams
configuration
Have appropriate software licences been purchased or reallocated licences used? Configuration
Have all new hardware components been recorded in the CMS? Configuration
Have all new software components been lodged in the definitive media library (DML) with Configuration
details recorded in the CMS?
Have all maintenance and upgrade plans been agreed, together with release policies, Release and
frequencies and mechanisms? deployment
Have all users been trained, and has user documentation been accepted and supplied to all Project manager
users?
Are all relationships, interfaces and dependencies with all other internal and external systems Project manager
and services documented, agreed and supported?
Have appropriate business managers signed off acceptance of the new service? Project manager

Service Design BOOK TEL v0_7.indb 14 08/07/2011 17:24