The Service Design Package

The SDP includes a great deal of information required by the service transition team. This includes the service charter, which details the expected utility and warranty, as well as the outline budgets and timescales. The service specification, service models, and architectural design required to deliver the new or changed service are also included, along with details of any constraints. In preparation, each new or changed service release is defined and its design documented. The SDP will contain a detailed description of how the service components will be assembled and integrated into a release package. The release and deployment plans and the service acceptance criteria are also included. Service design packages will be created (or updated) for all major changes.

The Service Transition and Release Policies

Transition planning and support will make use of the service transition and release policies. In Chapter 22, “Service Transition Principles,” we looked at transition policies in more detail. We shall look at policies specific to each of the service transition processes in the following chapters.

The release policy should be defined for one or more services and include numbering and naming conventions for different release types, the roles and responsibilities at each stage, and the expected frequency of releases.

The policy will include the requirement to deploy software from the definitive media library and the criteria for choosing and grouping changes into a release. Details of how the build, installation, and release distribution shall be automated will also be part of the policy.

Other elements of a release policy include details of what is required to capture and verify a release configuration baseline. The exit and entry criteria and authority for acceptance of the release into each stage and into each environment should be detailed together with the criteria and authorization to exit the early life support phase and complete the handover of the service to the service operation functions.

An example of a responsibility matrix for an organization that supports client/server applications is shown in Figure 23.1. Such a matrix will help to identify gaps and overlaps, and typical roles can be planned for the future. Study it, and if you can, try to imagine what one for your own organization might look like.

It is useful to define different types of releases; this helps set expectations. A typical example is categorizing releases as major, minor, and emergency. Typically, major releases may be defined as those containing large areas of new functionality, which may be to replace temporary fixes to problems with a permanent fix. A major release supersedes all preceding minor upgrades, releases, and emergency fixes. Minor releases may be defined as those containing small enhancements and fixes, some of which may replace earlier emergency fixes. A minor upgrade or release usually supersedes all preceding emergency fixes.

Finally, emergency releases would normally contain corrections to a small number of known errors or sometimes a high-priority enhancement.

The release policy will specify the frequency of releases and the criteria for an emergency release. Emergency releases should be kept to a minimum, so the service provider must always balance the need for regular enhancements and the risk and disruption these may cause. However, releases that are too spaced out will lead inevitably to more emergency changes.

All releases should have a unique identifier that can be used by service asset and configuration management.

Here is an example of a naming convention:

• The format is AA_n.n.n.
• Characters before the underscore identify the service.
• Characters after the underscore identify the specific release.
• Each major release will increment the first number.
• Characters to the right of decimal points represent successively minor releases.

Using those conventions, consider the name EW_2.3:

• The service is EW.
• The first number after the underscore is 2, signifying that this is major release 2.
• The next number is 3, meaning this is the third minor release applied to major release 2.
• Another minor release applied to major release 2 would be numbered EW_2.4.
• If instead an emergency release is required, it would be EW_2.3.1.
• A new major release would be numbered EW_3.0.
• A minor release applied to release 3 would be EW_3.1.

Transition Strategy

Each organization should choose an approach to service transition that suits their particular requirements. Organizations vary in the type of services they offer and the size of their operation. Their approach may be flexible or risk averse, and this will influence their choices regarding how frequently they wish to deploy a new release. So each organization needs to develop its own service transition strategy. This will define the overall approach to transition and the allocation of resources.

The strategy will cover the purpose, goals, and objectives of service transition for the organization and the context in which it operates. It will define what is within and outside the scope of transition and include any restrictions under which the organization has to operate (for example, standards or agreements or legal, regulatory, or contractual requirements). It will identify the various organizations and stakeholders involved in transition, such as third parties, strategic partners, suppliers and service providers, customers, and users. The organizational structure of service transition will be explored (we look at this in more detail in Chapter 28, “Organizing for Service Transition”).

The transition strategy will define the transition policies, processes, and practices, including interfaces between the process and the service provider. There are other processes and methodologies being used during transition, such as program and project management; the strategy will define how these should interact. The roles and responsibilities of those involved will be defined, together with the methods to be used for resource planning and estimation activities.

The policies and processes will include those for preparing for transition, such as evaluation of training requirements and how changes and releases are to be authorized. The aim is to create a robust, effective reusable process so the organization’s experience, expertise, tools, knowledge, and so forth can be reused.

The service transition strategy defines entry and exit criteria for each release stage and for stopping or restarting transition activities. It specifies the criteria for judging the success or failure of the transition.

It also identifies the requirements and content of the new or changed service and where and when the transition is to take place. It defines what is to be in each release, what the contents of the SDP should be, and requirements for environments to be used. It includes the planning and management of environments (for example, commissioning and decommissioning equipment).

The transition strategy will assign roles and responsibilities. This would include who is able to authorize changes, for example. If any training is required, it would be arranged for those needing it, together with any other knowledge transfer activities, such as drawing up FAQs.

The whole approach to service transition will be defined in the transition strategy. This would include a transition model covering each of the service transition lifecycle stages. The approach to managing changes and assets will be defined, including the baseline, evaluation, configuration audit and verification points, and the points where change authorization is needed. Any defined change windows would also be listed.

The strategy should explain the approach to how the estimation of resources and costs should be carried out and the steps that should be taken when preparing for a transition. The methods used to evaluate and authorize changes and plan the various stages of the release—including build, test, deployment, and early life support—should be described, together with a description of how errors should be handled, corrected, and controlled.

The strategy should also cover the management and control aspects of recording, progress monitoring, and reporting. Finally, details should be given regarding how the service performance will be measured, and the KPIs and improvement targets should be described.

The transition strategy should define the deliverables from transition activities, including mandatory and optional documentation for each stage and the expected format for each document. This documentation will include plans and reports and documentation for transition, change management, service asset and configuration management, releases, testing, builds, and so on.

As with any project, the key milestones will be described with the required budget and funding.

Service Transition Lifecycle Stages

The SDP will define the lifecycle stages of the transition. These stages will usually include acquiring and testing CIs and components and carrying out the build and test and service release test stages. The SDP also ensures that everything is in place for the new or changed service through a service operational readiness test. The remaining lifecycle stages will be the deployment and early life support of the service and the postimplementation review and closure. Remember, for each stage there will be exit and entry criteria and a list of mandatory deliverables.

Prepare for Service Transition The next stage is to prepare for service transition. It is important to ensure that everything required for the transition has been considered prior to the start of the transition process. All of the required input deliverables must be available and complete, and the RFCs must be scheduled for the deployment. The CMS must be updated with the baseline information, and everything must be checked before permission is granted to proceed.

Planning and Coordinating Service Transition A service transition plan describes the work environment, infrastructure, tasks, and activities required to release and deploy a release into the test environments and into production.

The plan will usually include a schedule of milestones, handover and delivery dates, and a list of the activities and tasks to be performed. The staffing, resource requirements, budgets, and timescales at each stage are detailed, and any issues and risks to be managed are listed in issue and risk registers. Finally, all plans should include lead times and contingency. The plan should be built as information becomes available. Use a service transition model, amended as required, and allocate and schedule the required resources.

Integrated Planning Good planning and management are essential for successful deployment of a release. In reality, there is not just one plan but a series of interlocking plans, which need to be integrated to be successful. Transition plans need to be linked to lower-level plans such as release build and test plans. The linked plans are then integrated with the change schedule and release and deployment management plans. Careful planning at the start will help with successful resource allocation, utilization, budgeting, and accounting.

The overall service transition plan should include the key activities to acquire the release components and package the release as well as build, test, deploy, evaluate, and proactively improve the service through early life support. It will also include the activities to build and maintain the service and the IT infrastructure, the systems and environments, and the measurement system to support the transition activities.

Adopting Program and Project Management Best Practices The plans for an individual service transition must be integrated with plans for other transitions taking place at the same time, using industry best practices for project and program management. At this point, it may become apparent that the required date is not feasible; reprioritize other work if required to free up the resources needed. Liaise with change management and release and deployment management throughout because changes made to the plan will impact those areas too.

Multiple releases and deployments should be managed as a program, with each significant deployment run as a project, typically using a framework such as PRINCE2 or the guidance in the PMBOK Guide. The actual deployment may be carried out by dedicated operations staff, by a team brought together for the purpose, and/or by external suppliers.

Significant deployments are complex projects in their own right. Planning needs to consider the people, application, hardware, software, documentation, and knowledge elements; this will mean subdeployments for each of these.

Review of the Plan All service transition and release and deployment plans should be reviewed. A possible checklist of what to review would include the following items:

• A contingency allowance has been made for unplanned costs or delays.
• The plans include an allowance for varying lead times.
• Plans are complete, up-to date, and authorized.
• Release dates and deliverables are defined.
• Cost and other impacts are considered and risks managed.
• CIs have been checked for compatibility.
• Changes in circumstance are reflected in amendments to the plan.
• People are ready for the deployment.
• The release is in line with the SDP.

Transition Process Support Service transition should provide support for all stakeholders to enable them to understand and follow the service transition framework of processes and supporting systems and tools. Support may be given to all stakeholders and should help them to follow the process correctly. Identifying subject matter experts from outside the service transition team may be helpful in the future. It’s important to remember that project managers are not always aware of ITIL best practices, so transition planning and support needs to provide support in this area.

Transition planning and support should provide administrative support for managing service transition changes and work orders, issues, risks, and deviations. It should support the tools and service transition processes and monitor the service transition performance, identifying possible improvements to be input into continual service improvement. Any changes affecting the baseline configuration items will be controlled through change management.

Managing communication throughout a service transition is essential. Communication plans should include a clear definition of the objectives of communication and all the relevant stakeholders. The content and frequency of communication for each type of stakeholder may vary at different stages of the transition. The appropriate communications channel for different stakeholders should be chosen; possible channels include newsletters, posters, emails, reports, and presentations. The plan should also define how successful communication will be measured.

Plans and progress should be communicated and made available to relevant stakeholders. The list of stakeholders is in the SDP; this list should be updated as required.

Service transition activities should be monitored to ensure that the transition is proceeding according to plan. The actual transitions should be compared to the integrated service transition plans and release and change schedules. The progress of each transition should be monitored periodically, especially at milestone or baseline points. Management reports on the status of each transition will identify any significant variances so that action can be taken. As transitions are being deployed into a live and changing environment, it is to be expected that periodic adjustments will be required to the plans to suit the new situation.

Policies

Laying down the principles behind the change process in one or more policy documents will help staff understand the seriousness with which this process is taken by senior management, and this, in turn, will help build a culture where change management is taken seriously and the agreed process is followed. This will increase the success rate of changes and releases, which will help build credibility for the process and reduce attempts to bypass it.

Ensuring adherence to best practice in this area can be challenging because pressure to meet deadlines and to cut costs encourages the cutting of corners by reducing testing and training. The existence of published policies will help such pressures to be resisted; this may even include a decision not to implement a required change due to these policies having been ignored.

Let’s look now at some of the possible policies supporting change management that an organization might adopt. The aim of these policies is to encourage zero tolerance for unauthorized changes. The process must align with business, project, and stakeholder change management processes to be effective. IT is not responsible for the business change process but should ensure that the IT process aligns to the business needs. Other policies are as follows:

• All changes must create business value, and the business benefits must be measured and reported.
• Prioritization of changes should follow the guidance laid down regarding innovation versus preventive versus detective versus corrective changes.
• Accountability and responsibilities for changes are laid down throughout the service lifecycle.
• Segregation of duty controls ensures that, for example, the person agreeing, the success of a test is not the person doing the testing.
• A single focal point for changes helps to minimize conflicting changes and potential disruption to supported environments.

Here are some other possible policies supporting change management that an organization might adopt:

• Work with access management to ensure people who are not authorized to make changes do not have access to supported environments.
• Work with other processes such as service asset and configuration management to detect unauthorized changes, and incident management to identify change-related incidents.
• Ensure that changes are implemented at suitable times, by specifying change windows and then enforcing them.
• Evaluate the risk of all changes that impact service.
• Measure the efficiency and effectiveness of the process.

Design and Planning Considerations

The design of a robust change management process should include any legislative or regulatory requirements that may exist within the organization. It should also consider the organizational roles and responsibilities required to ensure effective management of the process, along with the dependencies and relationships with other service management processes. Measurement is a key characteristic of any process, and suitable measures should be included to ensure that the process is working effectively. All of these aspects should be fully documented to ensure understanding of the complete process, including how changes are to be classified and authorized. Identification and classification of changes would include the change document identifiers to be used, the types of change documents required, templates for change documentation, and the expected content. The approach to prioritization of changes using impact and urgency should be specified, including the roles, responsibilities, and accountabilities.

Other design requirements for change management processes are as follows:

• Organizational roles and responsibilities such as those for independent testing and formal evaluation of change
• Change authorization levels and escalation rules and the composition of the CAB and ECAB
• Details of how changes should be planned and communicated to stakeholders
• How changes may be grouped into releases or change windows and the detailed procedures for raising, assessing, evaluating, and verifying changes
• Identification of dependencies and clashes between changes
• The interfaces with other service management processes, especially the provision of information to service asset and configuration management
• The measurement and reporting of changes

The change management process should be planned in conjunction with release and deployment management and service asset and configuration management. This helps the service provider evaluate the impact of the change on the current and planned services and releases.

Types of Change Requests

A change request is a formal communication seeking an alteration to one or more configuration items. This may be a request for change (RFC) document, or the request may be made by a call to the service desk or as a result of a project initiation document. Major changes may require a change proposal, which is created by the service portfolio management process. The procedures for different types of change should be appropriate for each type; minor changes should not require a lot of documentation. Similarly, the levels of authorization required should be appropriate for each level of change.

There are three different types of service changes:

• Many changes can be categorized as standard changes. These are low risk, relatively common, and follow a defined procedure. As a result, they do not need to be assessed each time they are requested; instead these changes are preauthorized.
• Emergency changes must be implemented as soon as possible—for example, to resolve a major incident or implement a security patch. These are normally defined as changes where the risk of not carrying out the change is greater than the risk of implementing it.
• All other changes are defined as normal changes.

Changes may be categorized as major, significant, and minor, depending on the cost and risk involved. This categorization may be used to identify an appropriate change authority.

As much use as possible should be made of devolved authorization, both through the standard change procedure and through the authorization of minor changes by change management staff.

Changes, RFCs, and Change Records

The terms change, change record, and RFC are often used inconsistently. The ITIL core guidance defines these terms as follows:

• Change: The addition, modification, or removal of anything that could have an effect on IT services, including changes to architectures, processes, tools, metrics, and documentation as well as changes to IT services and other configuration items.
• Change record: A record containing the lifecycle of a single change and referencing the affected configuration items (CIs). A change record is created for every request received and may be stored in the configuration management system or elsewhere in the service knowledge management system.
• Request for change (RFC): A formal proposal for a change to be made. It may be recorded on paper or electronically.

RFCs are used only to submit requests; they are not used to communicate the decisions of change management or to document the details of the change. A change record contains all the required information about a change, including information from the RFC, and is used to manage the lifecycle of that change.

Change Models and Workflows

A change model predefines how to handle a particular type of change; this can then be programmed into the support tool to manage the change, ensuring that every such change is handled in this way. Models are useful for common changes and also those requiring specialized handling, such as emergency changes that may need different authorization and may have to be documented retrospectively or any changes that require specific sequences of testing and implementation.

Change models are especially useful for standard changes resulting from service requests.

The change model would normally include the steps to be carried out to handle the change, including handling issues and unexpected events. The model would list the steps in chronological order, with dependencies or concurrent steps, and the responsibility for each step would be defined. Timescales and thresholds for completion of the actions and any escalation procedures are also included. The support tools used can then automate many of these aspects.

Change Proposals

Major changes that involve significant cost, risk, or organizational impact will usually be initiated through the service portfolio management process. Before the new or changed service is chartered, it is reviewed for its potential impact. Authorization of the change proposal does not authorize implementation of the change but allows the service to be chartered so that service design activity can commence.

The proposal contains a high-level description of the change, including utility and warranty levels and the business outcomes it supports. The full business case and an outline schedule for design and implementation of the change are the remaining contents.

When the change proposal is authorized, the change schedule is updated to include the proposed change. RFCs will then be used in the normal way to request authorization for specific changes.

Standard Changes (Preauthorized)

As previously discussed, standard changes are preauthorized by change management, and a documented procedure is followed to deliver a specific change. Every standard change should have a change model defining how it should be handled. Many standard changes are triggered by the request fulfilment process and may be directly recorded and passed for action by the service desk.

The crucial elements of a standard change include a defined trigger to initiate the change and a series of tasks that are well known, documented and proven, and preauthorized. Budgetary approval will be preauthorized or within the control of the change requester. Crucially, the risk involved in implementing the change is usually low and always well understood. A change model is usually associated with each standard change.

Standard changes should be identified early on when the change management process is being built. This helps avoid unnecessarily high levels of administration leading to staff resistance to the process.

Remediation

All changes must include a plan for dealing with failure; this plan must itself be tested. Understanding the remediation options helps in the assessment of the risk associated with the change—if a simple back-out is possible, the risk is reduced. Change plans should include decision points for when remediation is required and sufficient time for it to be carried out.

Change Authorities

Each change must be authorized by a change authority. The change authority could be a particular role, person, or group of people; for example, the security manager role may be required to authorize certain categories of change, or the authorization of each support team leader may be required. The levels of authorization are dependent upon the type, size, risk, and potential business impact of the change. Where changes affecting several sites in a large enterprise are planned, there may need to be authorization by a higher-level change authority such as a global CAB or the board of directors.

Depending on the culture of the organization, there may be many or few layers of authorization, and there may be delegated authority dependent on preagreed parameters.

An example of a change authorization hierarchy is shown in Figure 23.4. Each organization should formally document its own change authorization hierarchy, which may be very different to the example shown here. All change authorities should be documented in the CMS.

In this example, if change assessment at level 2, 3, or 4 detects higher levels of risk, the authorization request is escalated to the appropriate higher level for the assessed level of risk. The use of delegated authority from higher levels to local levels must be accompanied by trust in the judgement of those lower levels. The level at which change is authorized should rest where accountability for accepting risk and remediation exist. Should disputes arise over change authorization or rejection, there should be a right of appeal to the higher level. Changes that have been rejected should be formally reviewed and closed.

Standard Deployment

Figure 23.5 and Figure 23.6 show the equivalent process flow for some examples of standard changes.

After a change has been built and tested and the deployment procedure has been used successfully one or more times, it may be appropriate to use a standard deployment request change model for future deployments of the same change. This is much simpler than the full change management process flow. You can see an example of a process flow for this kind of standard change in Figure 23.5.

Some very low-risk changes may be delegated to service desk or other service operation staff as a change authority. The change model for this kind of standard change may be very simple, as shown in Figure 23.6.

Strategic Triggers

First we will examine changes triggers that are an output of strategy. Strategy may require changes to achieve specific objectives while minimizing costs and risks. There is no such thing as cost-free and risk-free strategic plans or initiatives; we can only try to minimize these. Let’s look at some examples of programs and initiatives that implement strategic changes.

Legal, regulatory, policy, or standards changes may require changes to services, as would organizational changes. Changes may result from an analysis of business, customer, and user activity patterns. Adding new services or updates to the service, customer, or contract portfolios or changing the sourcing model would also require the service provider to carry out changes. Finally, there are always new advancements in technology; the service provider may want to take advantage of them.

Changes to the services to be offered through the service portfolio and changes to the current services in the service catalog will trigger the change management process. These could include changes to service packages, service definitions or characteristics or to utility, warranty, or service levels, or capacity and resource requirements. Any changes to costs, service assets, or acceptance criteria could also trigger the process. Take a minute to consider all of these examples of possible triggers and consider the possible impact of each; it is the responsibility of change management to manage the possible impact while ensuring that the benefits are realized.

Operational Changes

Many requests from users result in operational changes; these could include a request for a password reset, a request for access, or a request to move an IT asset. These types of changes will often be managed as standard changes by the request fulfilment process.

Service operation functions will also implement changes via the normal and standard change procedures. They may be corrective, such as rebooting a server or restarting an application, or preventative, such as applying a service pack, which may prevent possible incidents. In either case, they may impact a shared service.

The final trigger comes from CSI and concerns changes to deliver continual service improvement. As a result of CSI actions, a requirement for a change may be identified. CSI may identify improvements in, for example, technology, processes, and documentation that are required to deliver an improvement in the service. These changes will be raised as RFCs, and their implementation could have unintended negative effects on service provision and on other CSI initiatives. They therefore need to be managed to minimize the risk.