Small Organizations

Each organization should consider all of the roles that it requires and how they can be combined within its organizational constraints to create a structure that meets its needs. Figure 28.1 shows an example of a structure for a small organization.

In this example of a small organization, there is a service transition manager who is the process owner, process manager, and process practitioner for transition planning and support.

The change, configuration, and release (CCR) manager is the process owner and the process manager for change management, service asset and configuration management (SACM), release and deployment management, and knowledge management. The CCR manager has a small team of practitioners who carry out specific activities for these processes.

The evaluation and test manager is the process owner and the process manager for change evaluation and for service validation and test. This manager also has a small team of practitioners.

Larger Organizations

In Figure 28.2, you can see the structure for a larger organization.

In this example for service transition in a larger organization, there is a central HQ organization, which includes all process owners as well as a change management team, release managers for each category of business application, and a validation and test team.

Each geographical area has its own process managers and practitioners for change management, SACM, and deployment and a knowledge manager.

Service Owner

The service owner is responsible for the initiation, transition, and ongoing maintenance and support of a particular service. Service ownership is as critical to service management as establishing ownership for processes that cross multiple departments or processes in a multiple-vendor environment.

They act as the prime customer contact and make sure delivery of the service meets the customer requirements and that there is effective reporting and monitoring. The service owner should represent the service at all meetings (such as service reviews) and represent the service across the organization. They will also identify service improvements and liaise with process owners across the lifecycle. They are accountable to the IT director for service delivery.

Process Owner

The next generic role is process owner. This role is responsible for ensuring that the process is fit for use and that it is being performed according to the agreed and documented standard and meets the process aims.

The process owner will define the strategy, policy, and standards and assist with process design. It is their responsibility to ensure that the process can be carried out by making sure relevant documentation is available and current. The process owner will assist with the design and maintenance of the process, including input into service improvement. Ensuring that the process is carried out requires the provision of education, resources, awareness, and training. The process should be regularly audited for effectiveness and efficiency.

Process Manager

The process manager role is accountable for the operational management of a process. There may be several process managers for one process, for example, regional change managers. The process manager role is often assigned to the person who carries out the process owner role, but the two roles may be separate in larger organizations.

The process manager is accountable for working with the process owner to plan and coordinate all process activities, ensuring that all activities are carried out as required throughout the service lifecycle. The process manager will appoint staff to the required roles and manage the resources assigned to the process. Obviously the process manager will be required to work with service owners and other process managers to ensure that services run smoothly. The role will also be involved in monitoring and reporting on process performance and identifying improvement opportunities for both service and process. This will require collaboration with the CSI manager.

Process Practitioner

A process practitioner is responsible for carrying out one or more process activities. In some organizations, and for some processes, the process practitioner role may be combined with the process manager role; in others there may be large numbers of practitioners carrying out different parts of the process.

The process practitioner’s responsibilities typically include carrying out one or more activities of a process. It is important that the process practitioner has an understanding of how their role contributes to the overall delivery of service and creation of value for the business. They will work with other stakeholders, such as their manager, coworkers, users, and customers, to ensure that their contributions are effective. The practitioner is responsible for making sure inputs, outputs, and interfaces for their activities are correct and creating or updating records to show that activities have been carried out correctly.

This concludes the review of the generic process roles. We will now move onto reviewing the specific roles associated with the service transition processes.

Service Transition Manager

Many organizations will have a person with the job title service transition manager. This job typically combines the roles of transition planning and support process owner and transition planning and support process manager. So we will now consider each of these roles.

Transition Planning and Support Process Owner

First let’s look at the transition planning and support process owner. Their responsibilities will include carrying out the generic process owner role and setting the scope and policies for service transition. They will also oversee the overall design of all service transition processes to ensure that they will work together to meet the transition needs of the business.

Transition Planning and Support Process Manager

The transition planning and support process manager’s responsibilities typically include carrying out the generic process manager role and managing and coordinating the functions that are involved in service transition. The manager will be responsible for budgeting and accounting for service transition activities and resources, including requests for resources. They will act as the prime interface for senior management for service transition planning and reporting. The process manager will also be responsible for coordinating service transition activities across projects, suppliers, and service teams (working with project managers and other personnel as required). This should ensure that the final delivery of each service transition meets the agreed customer and stakeholder requirements specified in the service design package.

Transition Planning and Support Process Practitioner

The transition planning and support practitioner’s responsibilities typically include maintaining and integrating plans for specific service transition. This will require the maintenance and monitoring of progress for service transition changes, issues, risks, and deviations. It should include tracking progress on actions and mitigation of risks as well as maintaining records and providing management information on resource use, project/service transition progress, and budgeted and actual spending. The practitioner will also be responsible for communicating with stakeholders.

Change Management Process Owner

The change management process owner’s responsibilities typically include the responsibilities of the generic process owner role for the change management process. They are responsible for designing the change authority hierarchy and criteria for allocating RFCs to change authorities. They will also be responsible for designing change models and workflows. The process owner will work with other process owners to ensure that there is an integrated approach to the design and implementation of change management, service asset and configuration management, release and deployment management, and service validation and testing.

Change Management Process Manager

The change management process manager’s responsibilities include the responsibilities of the generic process manager role and planning and managing support for change management tools and processes. They are responsible for maintaining the change schedule and projected service outage. The role is also responsible for coordinating interfaces between change management and other processes, especially service asset and configuration management and release and deployment management.

Change Initiator

Many different people in the organization may carry out the role of change initiator; it is not usually carried out by people who work in change management. Each change should have only a single change initiator, and they are responsible for identifying the requirement for a change. They will then be expected to complete and submit a change proposal if appropriate and complete and submit an RFC. They will be expected to attend CAB meetings, if invited, to provide further information about the RFC or change proposal and then review change when requested by change management, specifically before closure.

Change Practitioner

The change practitioner’s responsibilities include verifying that RFCs are correctly completed and allocated to appropriate change authorities based on defined criteria. They will also submit requests for evaluation to trigger the change evaluation process. It is the practitioners responsibility to formally communicate decisions of change authorities to affected parties. Because there will potentially be many different teams engaged in the delivery of a change (including build and test), the practitioner is responsible for monitoring and reviewing their activities to ensure that the work is carried out correctly. This will be carried out as part of the release and deployment management process for a change that is part of a release. The practitioner will also be responsible for publishing the change schedule and projected service outage and ensuring that they are available when and where needed.

Change Authority

There will normally be different change authorities for each category of change. The change authority’s responsibilities include reviewing specific categories of RFC and formally authorizing changes at agreed points in the change lifecycle. The change authority will participate in change reviews before changes are closed, including attending CAB meetings to discuss and review changes when required.

CAB Member

In many organizations, the CAB is the change authority for some categories of change. In other organizations, the CAB is just an advisory body. Some CAB members may also be change authorities for other specific categories of change.

The CAB member’s responsibilities include participating in CAB meetings as the authorized representative for a particular group or function. They are expected to prepare for CAB meetings by circulating RFCs within their own group and coordinating feedback. They will then be required to review RFCs and recommend whether they should be authorized. Other activities include reviewing successful and failed changes and unauthorized changes. As part of the process, CAB members will be responsible for reviewing the change schedule and providing information to help identify conflicts or resource issues and for reviewing the projected service outage and providing feedback on the impact of planned outages.

CAB Chair

If there is a single change advisory board (CAB), the CAB chair will almost always be the change manager. If there are multiple CABs, there may be multiple change managers, each chairing a different CAB.

The CAB chair’s responsibilities include deciding who should attend CAB meetings and then planning, scheduling, managing, and chairing CAB meetings. They will also be responsible for selecting RFCs, based on the change policy, for review at CAB meetings. These RFCs should be circulated in advance of CAB meetings to allow prior consideration. The CAB chair is also required to select successful and failed changes for review at CAB meetings.

If there is an emergency change, the CAB chair has the responsibility of convening the emergency change advisory board (ECAB) meetings for consideration of emergency changes.

SACM Process Owner

The SACM process owner’s responsibilities include carrying out the generic process owner role for the SACM process. This involves agreeing on and documenting the scope for SACM, including the policy for determining which service assets should be treated as configuration items. The role will be required to work with other process owners to ensure that there is an integrated approach to the design and implementation of SACM, change management, release and deployment management, and knowledge management.

SACM Process Manager

The SACM process manager’s responsibilities include carrying out the generic process manager role for the SACM process. They are specifically accountable to the organization for stewardship of the organization’s fixed assets that are under the control of IT. The role is responsible for defining the service assets that will be treated as configuration items and then ensuring that configuration data is available when and where it is needed to support other service management processes. The process manager is also responsible for planning and managing support for SACM tools and processes as well as coordinating interfaces between SACM and other processes, especially change management, release and deployment management, and knowledge management.

Configuration Analyst

The configuration analyst role will often be combined with the role of the SACM process manager or that of the configuration librarian, depending on the size, structure, and culture of the organization. The responsibilities include proposing the scope for service asset and configuration management and supporting the process owner and process manager in the creation of principles, processes, and procedures. The analyst will also assist in defining the structure of the configuration management system, including CI types, naming conventions, required and optional attributes, and relationships. Once this has been decided, the analyst will also have the responsibility for training staff in SACM principles, processes, and procedures and performing configuration audits.

Configuration Librarian

A configuration librarian is the custodian of service assets that are registered in the configuration management system. They are responsible for controlling the receipt, identification, storage, and withdrawal of all supported CIs. This should include maintaining status information on CIs and providing it as required. They are also responsible for normal housekeeping activities, such as archiving superseded CIs and assisting in conducting configuration audits.

The librarian is responsible for identifying, recording, storing, and distributing information about issues relating to service asset and configuration management.

Release and Deployment Process Owner

There are a number of release and deployment management roles that need to be performed in support of the release and deployment management process. These roles are not job titles, and each organization will have to define appropriate job titles and job descriptions for its needs. Many of these roles are combined in an organization.

The release and deployment management process owner’s responsibilities include carrying out the generic process owner role for the release and deployment management process. They will be responsible for designing release models and workflows. The process owner should also work with other process owners to ensure that there is an integrated approach to the design and implementation of change management, service asset and configuration management, release and deployment management, and service validation and testing.

Release and Deployment Process Manager

To avoid conflicts of interest, it is important that this role is not assigned to the person responsible for service validation and testing.

The release and deployment management process manager’s responsibilities include carrying out the generic process manager role for the release and deployment management process. They are responsible for planning and coordinating all resources needed to build, test, and deploy each release, including resources from other functions such as technical management or application management. This is a matrix management approach; the manager will not assume line management responsibility for the staff. The release and deployment manager is responsible for planning and managing support for release and deployment management tools and processes. They also ensure that change authorization is provided before any activity that requires it, for example, before a release is checked in to the definitive media library (DML) and before it is deployed to a live environment. The process manager is responsible for coordinating interfaces between release and deployment management and other processes, especially change management, SACM, and service validation and testing.

Release Packaging and Build Practitioner

In smaller organizations, this role may be combined with the role of the release and deployment management process manager. It may also be combined with the role of the deployment practitioner, and in some organizations, it may be carried out by personnel working for the technical management or application management functions.

The release packaging and build practitioner’s responsibilities include assisting in the design of the release package during the service design stage of the service lifecycle and in conjunction with personnel from other teams and functions. They will also establish the final release configuration, which should include knowledge, information, hardware, software, and infrastructure. The practitioner role is responsible for building and testing the release prior to independent testing, and that should include establishing and reporting outstanding known errors and workarounds. If appropriate, the practitioner will also provide input to support change authorization for check-in of the release to the DML.

Deployment Practitioner

This role is often combined with the role of release packaging and build practitioner. It may also be carried out by personnel from the technical management or application management functions.

The deployment practitioner’s responsibilities include helping to plan the deployment during the service design stage of the service lifecycle and in conjunction with personnel from other teams and functions. They will then ensure that all deployment activity has been authorized by change management. The practitioner is responsible for carrying out the final physical delivery of the deployment.

The practitioner role is responsible for coordinating release documentation and communications, including training for support teams and customers, and updating and distributing service management and technical release notes providing technical and application guidance and support throughout the release process, including known errors and workarounds. This role is also responsible for providing feedback on the effectiveness of the release as well as recording and reporting deployment metrics to ensure that these are within agreed SLAs.

Early Life Support Practitioner

This role will often be carried out by personnel from the technical management or application management functions. It may also be combined with the roles of release packaging and build practitioner or deployment practitioner.

The early life support practitioner’s responsibilities include providing IT service and business functional support from deployment to final acceptance and to ensure delivery of appropriate support documentation. The practitioner will provide release acceptance for provision of initial support, including support to assist the service desk in responding to incidents and errors detected within a new or changed service. As part of early life support, the practitioner should be adapting and perfecting elements that evolve with final usage, such as user documentation, support documentation (including service desk scripts) and data management (including archiving).

One of the key activities and responsibilities for the early life support practitioner is embedding activities for a new or changed service and dealing with the final transition of the service-to-service operation and continual service improvement. They should also be monitoring incidents and problems and undertaking problem management during release and deployment, raising RFCs as required. The responsibilities should also include providing initial performance reporting and undertaking service risk assessment based on performance.

Build and Test Environment Manager

This role will often be carried out by personnel from the technical management or application management functions. It may be combined with the deployment practitioner role.

Build and test environment manager responsibilities include ensuring that service infrastructure and application are built to design specification as well as planning the acquisition, build, implementation, and maintenance of ICT infrastructure. It is important that the build and test environment manager is responsible for ensuring that all components are from controlled sources.

They are also responsible for developing an integrated application software and infrastructure build and delivering appropriate build, operations, and support documentation for the build and test environments. They are there to manage the building, delivery, and maintenance of required test environments.

Service Validation and Testing Process Owner

The service validation and testing process owner’s responsibilities include carrying out the generic process owner role for the service validation and testing process. This role will be responsible for defining the overall test strategy for the organization. They will work with other process owners to ensure that there is an integrated approach to the design and implementation of change management, change evaluation, release and deployment management, and service validation and testing.

Service Validation and Testing Process Manager

To avoid conflicts of interest, it is important that this role is not assigned to the person responsible for release and deployment management.

The service validation and testing process manager’s responsibilities include carrying out the generic process manager role for the service validation and testing process. The manager will assist with the design and planning of test conditions, test scripts, and test data sets during the service design stage of the service lifecycle to ensure appropriate and adequate coverage and control throughout the transition.

The manager should be responsible for allocating and overseeing test resources, ensuring that test policies are adhered to, and verifying tests conducted by release and deployment management or other teams. They are responsible for managing test environment requirements and planning and managing support for service testing and validation tools and processes. The service validation and testing manager provides management reporting on test progress, test outcomes, success rates, issues, and risks.

Service Validation and Testing Process Practitioner

The service validation and testing practitioner’s responsibilities include conducting tests as defined in the test plans and designs and documented in the service design package. The practitioner should be responsible for recording, analyzing, diagnosing, reporting, and managing test events, incidents, problems, and retest, depending on agreed criteria. They will also be responsible for administering test assets and components.

Contribution of Other Roles to Service Validation and Testing

A number of other roles play a significant part in service validation and testing.

Change management personnel ensure that tests are developed that are appropriate for the authorized changes and that agreed testing strategy and policy are applied to all changes.

Developers and suppliers establish the root cause of test failures. For complex situations, this may require collaboration between testing staff and development, build, or supplier personnel.

Service design personnel design tests as an element of the overall design. For many services, standard tests will exist, possibly defined in a service transition model or a release and deployment model.

Customers and users perform acceptance testing. These roles should be able to cover the full range of user profiles and requirements and adequately sign off on the conformance of a new or changed service against the agreed requirements. They will already have played a major role in helping to design the acceptance-testing approaches during the service design stage of the service lifecycle.

Change Evaluation Process Owner

The change evaluation process owner’s responsibilities include carrying out the generic process owner role for the change evaluation process. They are responsible for working with other process owners to ensure that there is an integrated approach to the design and implementation of change management, change evaluation, release and deployment management, and service validation and testing.

Change Evaluation Process Manager

The change evaluation process manager’s responsibilities include carrying out the generic process manager role for the change evaluation process. They are also responsible for planning and coordinating all resources needed to evaluate changes. The manager should make sure change evaluation delivers evaluation reports and interim evaluation reports in time to ensure that change authorities are able to use them to support their decision-making.

Change Evaluation Process Practitioner

The change evaluation process practitioner’s responsibilities include using the service design and the release package to develop an evaluation plan as an input to service validation and testing. The role also includes establishing risks and issues associated with all aspects of the service transition (for example, through risk workshops). The practitioner should create an evaluation report as input to change management.

Knowledge Management Process Owner

In many organizations, this role will be combined with the knowledge management process manager role, and in very small organizations, both process owner and process manager roles may be combined with roles from service asset and configuration management.

The knowledge management process owner’s responsibilities include carrying out the generic process owner role for the knowledge management process. The manager is responsible for creating the overall architecture for identification, capture, and maintenance of knowledge within the organization.

Knowledge Management Process Manager

The knowledge management process manager’s responsibilities include carrying out the generic process manager role for the knowledge management process. The manager is responsible for ensuring that all knowledge items are made accessible to those who need them in an efficient and effective manner. This will include planning and managing support for knowledge management tools and processes and encouraging people throughout the service provider to contribute knowledge to the service knowledge management system (SKMS). The knowledge manager should act as an adviser to business and IT personnel on knowledge management matters, including policy decisions on storage, value, worth, and so on.

Knowledge Management Process Practitioner

In many organizations, the person carrying out this role is called a knowledge librarian. The knowledge management process practitioner’s responsibilities include identifying, controlling, and storing any information that is deemed to be pertinent to the services provided and is not available by other means. This process is not intended to duplicate existing knowledge.

The manager (or librarian) is responsible for maintaining controlled knowledge items to ensure that they are current, relevant, and valid. Part of the role will be monitoring publicity regarding knowledge information to ensure that information is not duplicated and that the SKMS is recognized as a central source of information.

Knowledge Creator

The knowledge creator role may be carried out by many different people in the organization. Creation and sharing of knowledge is often written into the job descriptions of people in many different roles within IT and the business.

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 the stages from service design to service operation for day-to-day management, and so without design and operations, it has no purpose.

Upstream Relationships for Service Transition

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, that is, by the output of the service design stage. Its very nature is therefore dependent on its relationship with “upstream areas.”

Logical Staff Mobility

Service operation staff will be involved in design and operation tasks directly via population of the service knowledge management system. The updates will be the experiences detected during service operation stages, such as through the incident-problem-error cycles. Capturing this information will drive informed and correct decision-making processes, which should facilitate more effective service transition. You can see this represented in Figure 28.5, showing the flow of experience.

To retain and make effective use of experience, staff may well find themselves allocated (fully or partially) from service operation functions 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 that they have helped design and implement into the live environment.

Expert advice on transition (as with design and operation) will also provide expert input to the development and maintenance of service strategy. This is known as logical staff mobility because staff are engaged in more than one lifecycle stage.

Many of the capabilities of a service that require testing and acceptance with transition are established, and the approach and measures to be adopted are set within the service design stage of the lifecycle.

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 operation procedures for supporting the new or changed service in live use. Service transition input is likely to affect most areas of the service operation stage.

Testing will share processes with service operation, possibly with some variations in procedure, for example, to accommodate the differing requirements and risk environments of analyzing 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, the errors are released into the live known error database, and notification is passed to continual service improvement via the SKMS, of which CSI will make extensive use.