Service Transition

Organizing for Service Transition

A characteristic of a process is that all related activities need not necessarily be limited to one specific organizational unit. SACM, for example, can be conducted in departments such as Service Operation, application management, network management, systems development and non-IT departments like procurement. Since processes and their activities run through a whole organization, the activities should be mapped to the existing IT departments or sections and coordinated by process managers. Once detailed procedures and work instructions have been developed, an organization will then map its staff to the activities of the process. Clear definitions of accountability and responsibility are critical success factors for any process implementation. Without this, roles and responsibilities within the new or changed process can be confusing, and individuals might revert to how the activities were handled before the new or changed procedures were put in place.

6.1 GENERIC ROLES

Responsibility for each process and service must be allocated for effective delivery of that service or process. All staff involved in process and service delivery need to understand these roles and to be aware of where that responsibility lies. These owner roles are not necessarily a person dedicated for each process or service. The two key roles, process owner and service owner, are set out below.

6.1.1 Process Owner Role

The process owner is responsible for ensuring that all activities defined within the process are undertaken and is responsible for:

Defining the process strategy
Assisting with process design
Ensuring that appropriate process documentation is available and current
Defining appropriate policies and standards to be employed throughout the process
Periodically auditing the process to ensure compliance to policy and standards
Periodically reviewing the process strategy to ensure that it is still appropriate and change as required
Communicating process information or changes as appropriate to ensure awareness
Providing process resources to support activities required throughout the Service Management lifecycle
Ensuring process technicians have the required knowledge and the required technical and business understanding to deliver the process, and understand their role in the process
Reviewing opportunities for process enhancements and for improving the efficiency and effectiveness of the process
Addressing issues with the running of the process
Providing input to the ongoing service improvement plan.

6.1.2 Service Owner Role

The service owner is responsible to the customer for the initiation, transition and ongoing maintenance and support of a particular service.

The service owner has the following responsibilities:

To act as prime customer contact for all service-related enquiries and issues
To ensure that the ongoing service delivery and support meet agreed customer requirements
To identify opportunities for service improvements, discuss with the customer and raise the RFC for assessment if appropriate
To liaise with the appropriate process owners throughout the Service Management lifecycle
To solicit required data, statistics and reports for analysis and to facilitate effective service monitoring and performance
To be accountable to the IT director or Service Management director for the delivery of the service.

6.2 ORGANIZATIONAL CONTEXT FOR TRANSITIONING A SERVICE

Other organizational units and third parties need to have clearly defined interface and handover points with Service Transition to ensure the delivery of the defined deliverables within the agreed schedule. Programmes, projects, Service Design and suppliers are responsible for the delivery of service assets and components in accordance with the requirements of the Service Design, SLAs and contracts in addition to initiating any changes that affect a service release or deployment.

Service Transition will acquire changes, service assets and components from these parties. An example Service Transition organization is illustrated in Figure 6.1 in addition to other teams within the IT services organization.

Figure 6.1 Example of Service Transition organization and its interfaces
Figure 6.1 Example of Service Transition organization and its interfaces

As shown above, there are interfaces to projects and business operations that need to be clearly defined. It is essential that throughout the Service Management lifecycle there is clear interaction and understanding of responsibility by all that neither element can work in isolation. It is critical that projects have a clear understanding of Service Design, transition and operations requirements and objective of delivery, and vice versa.

Often projects and programmes will work in isolation from Service Transition and operations, believing that they have no part to play in the ongoing service delivery. Similarly, transition and operations can ignore ongoing project activity; working on the basis that they will only be concerned about it once it is 'their turn' to deal with it. This is a very short-sighted approach and one that should be removed. Cooperation, understanding and mutual respect are critical to ensuring that new, changed and ongoing delivery of services to the customer are optimized.

Figure 6.2 illustrates the required interaction between programmes, projects and Service Management elements. During the release and deployment there will be interactions with the business, customers and users and these responsibilities are defined in this section.

Figure 6.2 Organizational interfaces for a Service Transition
Figure 6.2 Organizational interfaces for a Service Transition

6.3 ORGANIZATION MODELS TO SUPPORT SERVICE TRANSITION

Many people and processes are involved in Service Transition. Some of the key organization requirements that support the application of ITIL best practices for Service Transition are described in this section.

6.3.1 Management of Service Transition

Service Transition requires active management, with recognition of its key role in delivering effective IT services within an organization. One key element of this recognition is the allocation of the role of Service Transition manager.

An example of a function or organizational structure for Service Transition is shown in Figure 6.3.

Figure 6.3 Example of an organization for Service Transition
Figure 6.3 Example of an organization for Service Transition

6.3.2 Service Transition Roles And Responsibilities

The specific roles and responsibilities covered within this section relate primarily to Service Transition, although they will be used to some extent by other processes within the Service Management lifecycle. These are:

Service Transition management
Planning and support
Service Asset and Configuration Management and Change Management
Performance and risk evaluation
Service Knowledge Management
Service test management
Release and deployment
Release packaging and build
Deployment
Early life support
Build and test environment management.

Depending on the size of the organization and the scope of the service being transitioned, some of these roles will be combined and performed by one individual. However, service test management and physical testing must always be performed by resources independent of other functions or processes.

It is essential to recognize that all staff involved in Service Transition are responsible for:

Identifying and raising risks and issues, which may directly relate to their process area or may be something that they observe elsewhere within or outside of Service Transition
Being constantly aware of and understanding the business context in which they are working and understanding the customer's business needs of the services they are providing
Being fully aware of projects under way and the expected service delivery of those projects, including potential impact on their area of responsibility
Ensuring that they follow the published standards for documentation, change, asset and Configuration Management and Knowledge Management processes as well the incident and problem management processes. Where standards do not exist, raising this as a risk at the earliest opportunity.

6.3.2.1 The Service Transition Manager

The Service Transition manager has day-to-day management and control of the Service Transition teams and their activities. The prime responsibilities for this role a re:

Overall planning and management of Service Transition delivery including Continual Service Improvement
Managing and coordinating the Service Transition functions
Budgeting and accounting for Service Transition team activities and resources
Acting as the prime interface for senior management in terms of Service Transition planning and reporting
Making a final recommendation to the business and IT regarding the decisions to release and deploy into production
Ensuring all organizational policies and procedures are followed throughout transition
Ensuring the final delivery meets the agreed customer and stakeholder requirements specified in the Service Design.

6.3.2.2 Planning And Support

Planning and support may not be a direct responsibility of the Service Transition manager, as in some organizations this function may be consolidated into an overall Service Management office/IT planning responsibility. Regardless of where this function sits, the role must still be performed.

This function provides support for the Service Transition teams and people. The activities include:

Defining the requirements, processes and tools for Transition Planning and Support
Maintaining and integrating lower level plans to establish overall integrated transition plans, including planned vs actuals
Maintaining and monitoring progress on Service Transition changes, issues, risks and deviations including tracking progress on actions and mitigation of risks
Maintaining records on and providing management information on resource use, project/Service Transition progress, budgeted and actual spend
Managing and coordinating requests for resources
Coordinating Service Transition activities across projects, suppliers and service teams where appropriate
Publishing Service Transition performance statistics and identifying key areas for improvement
Undertaking formal quality reviews of the Service Transition, release and deployment plans and agreed transition activities in accordance with the quality management plan
Managing support for tools and Service Transition processes
Communicating with stakeholders.

6.3.2.3 Service Asset And Configuration Management And Change Management Roles

Service Design is responsible for designing the baselines appropriate for the service and identifying the relevant assets and CIs with input from the business change manager(s) and others who have responsibilities for delivering services and maintaining business continuity.

During the first stages of a project the programme or project office may be responsible for administering the Configuration Management process, maintaining copies of relevant documentation concerning the CIs, and controlling the release of CIs following appropriate approvals. At defined release points for a service and service package, the programme or project office will pass responsibility to Service Transition who will take responsibility for Configuration Management of the Cl documentation.

Responsibilities for reviewing and approving assets and CIs across the service lifecycle and during deployment need to be defined and allocated to individuals with appropriate skills and authority. Role specifications for the Change Management, Service Asset and Configuration Management teams need to be developed. Typical roles include:

Service asset manager
Configuration manager
Configuration analyst
Configuration administrator/librarian
CMS/tools administrator
Change manager.

Assign the configuration manager and other key roles as early as possible, because assigned individuals can then be involved in the implementation. For some operational activities Configuration Management will require staff who will adopt a diligent approach and pay due attention to detail.

The Service Asset Manager
The service asset manager has the following responsibilities:

Works to the overall objectives agreed with the IT services manager; implements the organization's service Asset Management policy and standards
Evaluates existing Asset Management systems and the design, implementation and management of new/improved systems for efficiency and effectiveness, including estimating and planning the work and resources involved, and monitoring and reporting on progress against plan
Agrees scope of the Asset Management processes, function, the items that are to be controlled, and the information that is to be recorded; develops Asset Management standards, Asset Management plans and procedures
Mounts an awareness campaign to win support for new Asset Management procedures; ensures that changes to the Asset Management methods and processes are properly approved and communicated to staff before being implemented; plans, publicizes and oversees implementation of new Asset Management systems
Arranges recruitment and training of staff
Manages the evaluation of proprietary Asset Management tools and recommends those that best meet the organization's budget, resource, timescale and technical requirements
Manages the Asset Management plan, principles and processes and their implementation
Agrees assets to be uniquely identified with naming conventions; ensures that staff comply with identification standards for object types, environments, processes, lifecycles, documentation, versions, formats, baselines, releases and templates
Proposes and/or agrees interfaces with Change Management, problem management, network management, release management, computer operations, logistics, finance and administration functions
Plans population of the asset DB; manages the asset DB, central libraries and tools; ensures regular housekeeping of the asset DB
Provides reports, including management reports (indicating suggested action to deal with current or foreseen shortcomings), impact analysis reports and asset status reports
Initiates actions needed to secure funds to enhance the infrastructure and staffing levels in order to cope with growth and change
Assists auditors to audit the activities of the Asset Management team for compliance with laid-down procedures; ensures corrective action is carried out.

The Configuration Manager
The configuration manager has the following responsibilities:

Works to the overall objectives agreed with the IT services manager; implements the organization's Configuration Management policy and standards
Evaluates existing Configuration Management Systems and the design, implementation and management of new/improved systems for efficiency and effectiveness, including estimating and planning the work and resources involved, and monitoring and reporting on progress against plan
Agrees scope of the Configuration Management processes, function, the items that are to be controlled, and the information that is to be recorded; develops Configuration Management standards, Configuration Management Plans and procedures
Mounts an awareness campaign to win support for new Configuration Management procedures; ensures that changes to the Configuration Management methods and processes are properly approved and communicated to staff before being implemented; plans, publicizes and oversees implementation of new Configuration Management Systems
Arranges recruitment and training of staff
Manages the evaluation of proprietary Configuration Management tools and recommends those that best meet the organization's budget, resource, timescale and technical requirements
Manages the Configuration Management Plan, principles and processes and their implementation
Agrees CIs to be uniquely identified with naming conventions; ensures that staff comply with identification standards for object types, environments, processes, lifecycles, documentation, versions, formats, baselines, releases and templates
Proposes and/or agrees interfaces with Change Management, problem management, network management, release management, computer operations, logistics, finance and administration functions
Plans population of the CMS; manages CMS, central libraries, tools, common codes and data; ensures regular housekeeping of the CMS
Provides reports, including management reports (indicating suggested action to deal with current or foreseen shortcomings), impact analysis reports and configuration status reports
Initiates actions needed to secure funds to enhance the infrastructure and staffing levels in order to cope with growth and change
Assists auditors to audit the activities of the Configuration Management team for compliance with laid-down procedures; ensures corrective action is carried out.

The Configuration Analyst
The configuration analyst has the following responsibilities:

Proposes scope of the Asset and Configuration Management processes, function, the items that are to be controlled, and the information that is to be recorded; develops Asset and Configuration Management standards, plans and procedures
Trains Asset and Configuration Management specialists and other staff in Asset and Configuration Management principles, processes and procedures
Supports the creation of the Asset and Configuration Management Plans and principles and their implementation
Creates Asset and Configuration Management processes and procedures, which includes Cl registration procedures; access controls and privileges; ensures that the correct roles and responsibilities are defined in the Asset and Configuration Management Plans and procedures
Proposes and agrees with the asset and configuration manager ClS to be uniquely identified with naming conventions; ensures that developers and configuration system users comply with identification standards for object types, environments, processes, lifecycles, documentation, versions, formats, baselines, releases and templates
Liaises with the configuration administrator/librarian on population of the asset and CMS; manages asset and CMS, central libraries, common codes and data; ensures regular housekeeping of the asset and CMS
Uses or provides the asset and CMS to facilitate impact assessment for RFCs and to ensure that implemented changes are as authorized; creates change records, configuration baselines, and package release records in order to specify the effect on Cls of an authorized change; ensures any changes to change authorization records are themselves subject to Change Management procedures; ensures that the asset and CMS is updated when a change is implemented
Uses the asset and CMS to help identify other Cls affected by a fault that is affecting a Cl
Performs configuration audits to check that the physical IT inventory is consistent with the asset and CMS and initiates any necessary corrective action
Creates and populates project libraries and CM system; checks items and groups of items into the CM tools
Accepts baselined products from third parties and distributes products
Builds system baselines for promotion and release
Maintains project status information and status accounting records and reports
Monitors problems (test incidents) and maintains database for collection and reporting of metrics.

The Configuration Administrator/Librarian
The configuration administrator/librarian is the custodian and guardian of all master copies of software, assets and documentation CIs registered with Asset and Configuration Management. The major tasks of this role are to:

Control the receipt, identification, storage, and withdrawal of all supported CIs
Provide information on the status of CIs
Number, record, store and distribute Asset and Configuration Management issues.

The configuration administrator/librarian has the following specific responsibilities:

Assists Asset and Configuration Management to prepare the Asset and Configuration Management Plan
Creates an identification scheme for Configuration Management libraries and the Definitive Media Library (DML)
Creates an identification scheme for assets and the Definitive Spares (DS)
Creates libraries or other storage areas to hold CIs
Assists in the identification of products and CIs
Maintains current status information on CIs
Accepts and records the receipt of new or revised configurations into the appropriate library
Archives superseded Cl copies
Holds the master copies
Administers configuration control process:

Distributes change requests to individual team members for impact assessment
Validates completeness of change requests
Routes change requests to appropriate authority for approval
Progresses and tracks change requests through to completion
Reports on change requests
Records decisions about change requests
Issues copies of products for review, change, correction or information when authorized to do so
Maintains a record of all copies issued
Notifies holders of any changes to their copies
Collects and retains information that will assist in the assessment of what CIs are impacted by a change to a product

Produces configuration status accounting reports
Assists in conducting configuration audits
Liaises with other configuration libraries where CIs are common to other systems.

The CMS/Tools Administrator
The CMS/tools administrator has the following responsibilities:

Evaluates proprietary Asset and Configuration Management tools and recommends those that best meet the organization's budget, resource, timescale and technical requirements; directly or indirectly customizes proprietary tools to produce effective Asset and Configuration Management environments in terms of databases and software libraries, workflows and report generation
Monitors the performance and capacity of existing Asset and Configuration Management systems and recommends improvement opportunities and undertakes standard housekeeping and fine tuning under change control
Liaises with the configuration analyst and administrator/librarian on population of the asset and CMS; provides technical administration and support for asset and CMS, central libraries, tools' common codes and data; undertakes regular technical housekeeping of the asset and CMS
Ensures the integrity and operational performance of the CM systems.

The Configuration Control Board
The Configuration Control Board is required to ensure that the overarching intention and policies of Configuration Management are employed throughout the Service Management lifecycle and with specific consideration for every aspect of the complete service. The Board has the following responsibilities:

Defines and controls the service configuration baselines in terms of core and support services, applications, information, service, technical, infrastructure - ensuring that they meet the requirements established in the Service Design
Reviews changes in the service configuration for compliance with standards, contractual and internal requirements
Originates requirement changes for service configuration to comply with contract change requests.

In some organizations, the Configuration Control Board will be combined with change, thereby providing a holistic view of the current and proposed services and service models, enabling better control, change evaluation, impact assessment and understanding.

The Change Authority
Formal authorization is obtained for each change from a change authority that may be a role, person or a group of people. The levels of authorization for a particular type of change should be judged by the type, size or risk of the change, e.g. changes in a large enterprise that affect several distributed sites may need to be authorized by a higher-level change authority such as a Global Change Board or the Board of Directors.

The culture of the organization dictates, to a large extent, the manner in which changes are authorized. Hierarchical structures may well impose many levels of change authorization, while flatter structures may allow a more streamlined approach.

A degree of delegated authority may well exist within an authorization level, e.g. delegating authority to a change manager according to pre-set parameters relating to:

Anticipated business risk
Financial implications
Scope of the change (e.g. internal effects only, within the finance service, specific outsourced services).

An example of authorization hierarchy is shown in Figure 4.5, Example of a change authorization model.

The Change Manager
The main duties of the change manager, some of which may be delegated, are listed below:

Receives, logs and allocates a priority, in collaboration with the initiator, to all RFCs; rejects any RFCs that are totally impractical
Tables all RFCs for a CAB meeting, issues an agenda and circulates all RFCs to CAB members in advance of meetings to allow prior consideration
Decides which people will come to which meetings, who gets specific RFCs depending on the nature of the RFC, what is to be changed, and people's areas of expertise
Convenes urgent CAB or ECAB meetings for all urgent RFCs
Chairs all CAB and ECAB meetings
After consideration of the advice given by the CAB or ECAB, authorizes acceptable changes
Issues change schedules, via the service desk
Liaises with all necessary parties to coordinate change building, testing and implementation, in accordance with schedules
Updates the change log with all progress that occurs, including any actions to correct problems and/or to take opportunities to improve service quality
Reviews all implemented changes to ensure that they have met their objectives; refers back any that have been backed out or have failed
Reviews all outstanding RFCs awaiting consideration or awaiting action
Analyses change records to determine any trends or apparent problems that occur; seeks rectification with relevant parties
Closes RFCs
Produces regular and accurate management reports.

Change Advisory Board
A Change Advisory Board (CAB) is an advisory body. It needs to have appropriate terms of reference (e.g. meeting regularity, scope of influence, and links to programme management).

To understand more about the specific role and responsibilities of the CAB, see paragraph 4.2.6.8.

6.3.2.4 Performance And Risk Evaluation Management

The following roles all provide input into the performance and risk evaluation of the Service Transition processes and key decision making, e.g. stopping or holding the deployment.

The Performance And Risk Evaluation Manager
The performance and risk evaluation manager has the following responsibilities:

Uses Service Design and release package to develop the evaluation plan to input to service testing
Establishes risks and issues associated with all aspects of the Service Transition through risk workshops etc.
Provides evaluation report to input to Change Management.

6.3.2.5 Service Knowledge Management
Knowledge Management requires effective and authoritative ownership within an organization. The role of the Knowledge Management process owner is crucial, in that it will design, deliver and maintain the Knowledge Management strategy, process and procedures.

The Knowledge Management Process Owner
The Knowledge Management process owner has the following responsibilities:

Undertakes the Knowledge Management role, ensuring compliance with the organization's policies and processes
Is the architect of knowledge identification, capture and maintenance
Identifies, controls and stores any information deemed to be pertinent to the services provided, which is not available via any other means
Maintains the controlled knowledge items to ensure currency
Ensures all knowledge items are made accessible to those who need them in an efficient and effective manner
Monitors publicity regarding the knowledge information to ensure that information is not duplicated and is recognized as a central source of information etc.
Acts as an adviser to business and IT personnel on Knowledge Management matters, including policy decisions on storage, value, worth etc.

6.3.2.6 Service Test Manager

Service test management is primarily responsible for the test support and the test team(s) functions involved with the specific Service Transition. The service test manager will report to the Service Transition manager as will the release and deployment manager; however, these roles should always be undertaken by separate people, and never be combined, to ensure that there is always independent testing and test verification.

The service test manager has the following responsibilities:

Defines the test strategy
Designs and plans testing conditions, test scripts and test data sets to ensure appropriate and adequate coverage and control
Allocates and oversees test resources, ensuring test policies are adhered to
Provides management reporting on test progress, test outcomes, success rates, issues and risks
Conducts tests as defined in the test plans and design
Records, analyses, diagnoses, reports and manages test events, incidents, problems and retest dependent on agreed criteria
Manages test environment requirements
Verifies tests conducted by release and deployment teams
Administers test assets and components.

Test Support
The prime responsibility of the test support team is to provide independent testing of all components delivered within the Service Transition programme or project. Responsibilities required to deliver successful service testing include the following, however, not all of these are the direct responsibility of the test support team:

The change manager is responsible for ensuring that tests are developed appropriate to approved changes and that agreed testing strategy and policy is applied to all changes.
Test analysts carry out the tests as set out in the testing plans and/or service package.
The developer/supplier is responsible for establishing the root cause of test failures - the fault in the service component that made the test fail. For complex situations this may require collaboration between testing staff and development/build/supplier personnel. It should always be accepted as a possibility that faults can lie within the testing design as well as within design/development.
Service Design will design the test, as an element of the overall Service Design. For many services, standard tests will exist, perhaps contained within the transition model chosen as already accepted as appropriate for the type of new or changed service under consideration.
Customers and users perform customer and user acceptance testing. Such user resource should be able to cover the full range of user profile and requirements, and adequately sign off the conformance of a new or changed service. Users will already have played a major role in helping to design the acceptance testing approaches during the design phase.

6.3.2.7 Release And Deployment

Release and deployment is primarily responsible for managing all aspects of the end-to-end release process. The release and deployment manager will report to the Service Transition manager as will the service test manager; however these roles should always be undertaken by separate people, and never be combined, .to ensure that there is always independent testing and test verification.

The Release And Deployment Manager
The release and deployment manager is responsible for the planning, design, build, configuration and testing of all software and hardware to create the release package for the delivery of, or changes to, the designated service.

The release and deployment manager has the following responsibilities:

Manages all aspects of the end-to-end release process
Updates the SKMS and CMS
Ensures coordination of build and test environment team and release teams
Ensures teams follow the organization's established policies and procedures
Provides management reports on release progress
Service release and deployment policy and planning
Deals with release package design, build and configuration
Deals with release package acceptance including business sign-off
Deals with service roll-out planning including method of deployment
Deals with release package testing to predefined Acceptance Criteria
Signs off the release package for implementation
Deals with communication, preparation and training
Audits hardware and software before and after the implementation of release package changes
Installs new or upgraded hardware
Deals with storage and traceability/auditability of controlled software in both centralized and distributed systems
Deals with release, distribution and the installation of packaged software.

However, some of these responsibilities will be delegated to the relevant release team sub-process.

The main components to be controlled are:

Service documentation including:
Service Portfolio
Service catalogue
Service level agreement, OLAs and UCs
Service Design and specification
Application programs developed in-house
Externally developed software (including standard offthe-shelf software as well as custom-written software)
Utility software
Supplier-provided systems software
Hardware, and hardware specifications
Assembly instructions and documentation, including user manuals.

All deliverables need to be managed effectively, from development or purchasing, through customization and configuration, through testing and implementation, to operation in the live environment.

6.3.2.8 Release Packaging And Build

Release packaging and build management is the flow of work (establish requirements, design, build, test, deploy, operate and optimize) to deliver applications and infrastructure that meet the Service Design requirements.

The Release Packaging And Build Manager
The release packaging and build manager has the following responsibilities:

Establishes the final release configuration (e.g. knowledge, information, hardware, software and infrastructure)
Builds the final release delivery
Tests the final delivery prior to independent testing
Establishes and reports outstanding known errors and workarounds
Provides input to the final implementation sign-off process.

The release packaging and build manager cannot perform this role in isolation; other functions with which there will be significant interface are: Security Management

Test management
Change and Service Asset Configuration Management
Capacity management
Availability management
Incident management
Quality management.

6.3.2.9 Deployment

Deployment staff have the following responsibilities:

Deal with the final physical delivery of the service implementation
Coordinate release documentation and communications, including training and customer,
Service Management and technical release notes
Plan the deployment in conjunction with change and Knowledge Management and SACM
Provide technical and application guidance and support throughout the release process, including known errors and workarounds
Provide feedback on the effectiveness of the release
Record metrics for deployment to ensure within agreed SLAs.

6.3.2.10 Early Life Support

It is often believed that early life support starts when the service has actually been transitioned into operational use. This is not the case. Early life support should be considered as an integral role within the release and deployment phase. Early life support staff have the following key responsibilities:

Provide IT service and business functional support from prior to final acceptance by Service Operations
Ensure delivery of appropriate support documentation
Provide release acceptance for provision of initial support
Provide initial support in response to incidents and errors detected within a new or changed service
Adapt and perfect elements that evolve with initial usage, such as:
User documentation
Support documentation including service desk scripts
Data management, including archiving
Embed activities for a new or changed service
Deal with formal transition of the service to Service Operations and CSI
Monitor incidents and problems, and undertake problem management during release and deployment, raising RFCs as required
Provide initial performance reporting and undertake service risk assessment based on performance.

6.3.2.11 Build And Test Environment Management

The build and test environment function is primarily to ensure that all the relevant people have the appropriate environments, test data, versioned software etc. available at the time that they need it and for the right purpose. As environment resources are normally limited, this role performs a coordinating and sometimes arbitrary role to ensure that resources are used to maximum effect.

Build and test environment staff have the following key responsibilities:

Ensure service infrastructure and application are built to design specification
Plan acquisition, build, implementation and maintenance of ICT infrastructure
Ensure build delivery components are from controlled sources
Develop an integrated application software and infrastructure build
Deliver appropriate build, operations and support documentation for the build and test environments prior to handover to Service Operations
Build, deliver and maintain required testing environments.

6.4 SERVICE TRANSITION RELATIONSHIP WITH OTHER LIFECYCLE STAGES

Service Transition is presented as a discrete lifecycle step, but this should not be taken to imply that it can stand alone. Service Transition exists to deliver the concepts documented within Service Design through to Service Operations for day-to-day management, and so without design and operations it has no purpose.

6.4.1 Upstream Relationships For Service Transition

6.4.1.1 Logical Staff Mobility

Service Transition takes its shape and input from the strategy set by the organization and from the new or changed services it is charged with bringing into live operation, i.e. by the output of the Service Design stage. Its very nature is therefore dependent on its relationship with 'upstream areas'.

In most organizations, many staff will deliver tasks appropriate to more than one lifecycle stage. Indeed, the skills and experience accumulated by Service Transition and Service Operations staff will typically be valuable in the stages upstream of their nominal focus.

Figure 6.4 Flow of experience
Figure 6.4 Flow of experience

Specifically, Service Transition will depend on appropriate experience from operations skilled staff to deliver much of the knowledge required to make key decisions, based on predicting likely successful practice based on previous behaviour of systems in similar situations, as shown in Figure 6.4.

When Service Design establishes the best transition approach, and when, within Service Transition, the continued viability of that approach is assessed, Service Transition and Service Operation are best placed to play the role of subject matter expert, and provide input to the assessment and evaluation of the design's initial and ongoing viability.

Service Operation people will be involved in (design and) operations tasks directly via population of the Service Knowledge Management System with precedents and experiences detected during Service Operation stages - e.g. through incident-problem-error cycles. This will drive informed and correct decision making processes and facilitate more effective Service Transition.

In order to retain and make effective use of experience, staff may well find themselves allocated (fully or partially) from operations tasks to support a design exercise and then follow that service through Service Transition. They may then, via early life support activities, move into support of the new or changed services they have been involved in designing and implementing into the live environment.

Expert advice on transition (as with design and operations) will also provide expert input to the development and maintenance of Service Strategy.

6.4.1.2 Process Communications

Many of the capabilities of a service that require testing and acceptance with transition are established and approach and measures set within design. As described above, this exercise is likely to have involved Service Transition staff, either through direct involvement (perhaps even formal secondment) or through consultation and expert advice.

6.4.2 Downstream Process And Procedure Influence

Many elements initiated or perfected during Service Transition will be established and become key elements within Service Operation.

During transition testing incidents will be detected that reveal errors within the new or changed service. The nature and identified resolution of these errors will provide direct input to the Service Operations procedures for supporting the new or changed service in live use. Service Transition input is likely to affect most areas of the operations stage.

Testing will share processes with operations, possibly with some variations in procedure, e.g. to accommodate the differing requirements and risk environments of analysing and rectifying errors in testing and live environments.

Where testing detects errors in a new or changed service that are not significant enough to prevent the release of the service, these errors are released into the live known error database, and notification is passed to Continual Service Improvement, via the SKMS, which CSI will make extensive use of.