Introduction to PPO Tutorial

1.1 Introduction to PPO

Hello and Welcome to the Introduction on Planning, Protection and Optimization. This is the first learning unit of the syllabus prescribed by the Cabinet Office. Let’s begin with the agenda.

1.2 Introduction to PPO

In this learning unit we will learn about Service design purpose, objective, scope value to business followed by processes within ppo, design co-ordination and IT service management.

1.3 Service Design - Purpose

Now to start with let us understand the purpose of the Service design phase. The purpose of the service design stage of the lifecycle is to design IT services, together with the governing IT practices, processes and policies, to realize the service provider’s strategy and to facilitate the introduction of these services into supported environments ensuring quality service delivery, customer satisfaction and cost-effective service provision. Let us understand the objective of the service design phase in the next slide.

1.4 Service Design - Objectives

The objective of service design is to design IT services so effectively that minimal improvement during their lifecycle will be required. However, continual improvement should be embedded in all service design activities to ensure that the solutions and designs become even more effective over time, and to identify changing trends in the business that may offer improvement opportunities. Service design activities can be periodic or exception-based when they may be triggered by a specific business need or event. Moving on, Let us understand the value that service design as a phase contributes to the service lifecycle.

1.5 Service Design - Value to Business

Each stage in the ITIL Service Lifecycle provides value to business. For example, service value is modelled in Service Strategy; the cost of the service is designed, predicted and validated in Service Design and Service Transition; and measures for optimization are identified in Continual Service Improvement. With good Service Design, it is possible to deliver quality, cost-effective services and to ensure that the business requirements are being met. The benefits mentioned in the slide result from good Service Design practice: • Reduced Total Cost of Ownership (TCO) can only be minimized if all aspects of services, processes and technology are designed properly and implemented against the design • Improved quality of service can be achieved as both service and operational quality will be enhanced • Improved consistency of service is one of the major aspect that’s being added as services are designed within the corporate strategy, architectures and constraints • Easier implementation of new or changed services can be achieved as there is an integrated and full Service Design and the production of comprehensive SDPs • Improved service alignment can be achieved with the involvement from the conception of the service, ensuring that new or changed services match business needs, with services designed to meet Service Level Requirements • More effective service performance: with incorporation and recognition of Capacity, Financial Availability and IT Service Continuity Plans • Improved IT governance: assist with the implementation and communication of a set of controls for effective governance of IT • More effective Service Management and IT processes: processes will be designed with optimal quality and cost-effectiveness • Improved information and decision-making: more comprehensive and effective measurements and metrics will enable better decision-making and continual improvement of Service Management practices in the design stage of the Service Lifecycle.

1.6 Service Design - Basics

If services or processes are not designed they will evolve organically. If they evolve without proper controls, the tendency is simply to react to environmental conditions that have occurred rather than to understand clearly the overall vision and needs of the business. Designing to match the anticipated environment is much more effective and efficient, but often impossible – hence the need to consider iterative and incremental approaches to service design. Iterative and incremental approaches are essential to ensure that services introduced to the live environment continually adapt in alignment with evolving business needs. In the absence of formalized service design, services will often be unduly expensive to run, prone to failure, resources will be wasted and services will not be fully aligned to business needs. It is unlikely that any improvement programme will ever be able to achieve what proper design should achieve in the first place. Without service design, cost-effective service is not possible. Adopting and implementing standardized and consistent approaches for service design will: • Enable projects to estimate the cost, timing, resource requirement and risks associated with the service design stage more accurately • Result in higher volumes of successful change • Make design methods easier for people to adopt and follow • Enable service design assets to be shared and reused across projects and services • Reduce delays from the need to redesign prior to completion of service transition • Improve management of expectations for all stakeholders involved in service design including customers, users, suppliers, partners and projects • Increase confidence that the new or changed service can be delivered to specification without unexpectedly affecting other services or stakeholders • Ensure that new or changed services will be maintainable and cost-effective. Let us proceed to learn about the processes of service design in the next slide.

1.7 Planning Protection and Optimization - Processes

Processes that support the Service Lifecycle are • Capacity Management • Availability Management • Information Security • IT Service Continuity • Demand Management We will discuss each one of these in detail in the coming slides. Next, let us look at the inputs of service design.

1.8 Service Design - Inputs

Here are the inputs that go into the service design phase. Corporate visions, strategies, objectives, policies and plans go as an input from the service strategy phase. Constraints and requirements for compliance with legislated standards and regulations also act as input from strategy phase. From transition Service Transition plans which includes Change, Configuration and Release and Deployment Management Plans comes as an input to service design phase. Service acceptance test from service operation goes as one of the inputs to the service design phase. And from CSI any improvement from the audit and the stakeholder’s perspective goes as an input for the Design phase. In the next slide we will look at the outputs of the service design phase.

1.9 Service Design - Outputs

We have already seen the inputs of the service design phase, there is certainly some outputs as well. Here let us understand the outputs for the Service design phase. The deliverables from the design activities holistically can be termed as suggested revisions to IT strategies and policies with revised designs, plans and technology and management architectures, including: ? The IT infrastructure and infrastructure management and environmental strategy, designs, plans, architectures and policies ? The applications and data strategies, designs, plans, architectures and policies ? Designs for new or changed services, processes and technologies ? Process review and analysis reports, with revised and improved processes and procedures ? Revised measurement methods and processes ? Managed levels of risk, and risk assessment and management reports ? Business cases and feasibility studies, together with Statements of Requirements (SORs) and Invitations to Tender (ITTs) ? Comments and feedback on all other plans ? Business benefit and realization reviews and reports.

1.10 Objectives of Design Co-ordination

Now we are stepping into one of the processes in service design phase. As per the syllabus it is not a part of PPO but we have felt the need of discussing this process at the beginning as this forms an integral part of the entire course. To start with let’s understand the objectives of the design coordination process The objectives of the design coordination processes is to ensure consistent designing of appropriate services, service management information systems, architectures, technology, processes, information and metrics to meet current and evolving business outcomes and requirements. It is also responsible for coordinating all design activities across projects, changes, suppliers and support teams, and manage schedules, resources and conflicts where required Planning and coordination of the resources and capabilities required to design new or changed services is the main activity Producing service design packages (SDPs) based on service charters and change requests comes as an output for the process And hence ensuring that appropriate service designs and or SDPs are produced and that they are handed over to service transition as agreed is its responsibility The other objectives for this process would be to: • Manage the quality criteria, requirements and handover points between the service design stage and service strategy and service transition • Ensure that all service models and service solution designs conform to strategic, architectural, governance and other corporate requirements • Improve the effectiveness and efficiency of service design activities and processes • Ensure that all parties adopt a common framework of standard, reusable design practices in the form of activities, processes and supporting systems, whenever appropriate • Monitor and improve the performance of the service design lifecycle stage. Let us proceed to learn on the scope of the design coordination.

1.11 Design Co-ordination - Scope

The scope of the design coordination process includes all design activity, particularly all new or changed service solutions that are being designed for transition into (or out of, in the case of a service retirement) the live environment. Some design efforts will be part of a project, whereas others will be managed through the change process alone without a formally defined project. Some design efforts will be extensive and complex while others will be simple and swift. Not every design activity requires the same level of rigor to ensure success, so a significant number of design efforts will require little or no individual attention from the design coordination process. Most design coordination process activity focuses around those design efforts that are part of a project, as well as those that are associated with changes of defined types. Typically, the changes that require the most attention from design coordination are major changes, but any change that an organization believes could benefit from design coordination may be included. Each organization should define the criteria that will be used to determine the level of rigour or attention to be applied in design coordination for each design. Some organizations take the perspective that all changes, regardless of how small in scope, have a ‘design’ stage, as it is important that all changes have clear and correct plans for how to implement them. In this perspective, the lifecycle stage of service design still occurs, even if the designs for simple or standard changes are usually pre-built and are reused frequently and quickly. Sometimes the stage is quite complex and long and sometimes it is simply a rapid check that the right ‘design’ (procedure) is being used. Other organizations take the perspective that only changes that fit certain criteria, such as those associated with a project or major change, have a formal service design stage. In this perspective, changes that fail to meet the agreed criteria may be considered out of the scope of this process. Whichever perspective is adopted by an organization, the end result should be more successful changes that deliver the required business outcomes with minimal disruption or other negative impacts on business operations. If an organization’s approach produces that result, then the organization is performing design coordination correctly. In the next slide we will look at the value of the design coordination.

1.12 Design Co-ordination - Value

The main value of the design coordination process to the business is the production of a set of consistent quality solution designs and SDPs that will provide the desired business outcomes. Through the work of design coordination organizations can: Achieve the intended business value of services through design at acceptable risk and cost levels • It can minimize rework and unplanned labour costs associated with reworking design issues during later service lifecycle stages • Design Coordination support the achievement of higher customer and user satisfaction and improved confidence in IT and in the services received • It also ensures that all services conform to a consistent architecture, allowing integration and data exchange between services and systems • It provides improved focus on service value as well as business and customer outcomes • Design Coordination develops improved efficiency and effectiveness • of all service design activities and processes, thereby supporting higher volumes of successful change delivered in a timely and cost-effective manner • It achieves greater agility and better quality in the design of service solutions, within projects and major changes. Let us look what role does design coordination play in PPO in the next slide.

1.13 Design Co-ordination - Role of Design Coordination within PPO

As mentioned earlier Design coordination holds a very important role within coordination process in PPO. Overall lifecycle stage activities should include defining and maintaining policies and methods, planning design resources and capabilities, coordinating design activities, managing design risks issues and improvisation of service design. The slide also gives you details on individual design activities.

1.14 Design Co-ordination - Interfaces

Design coordination principal interfaces to the adjacent stages of the lifecycle are: • Service strategy: using information contained within the IT strategy and service portfolio • Service transition: with the handover of the design of service solutions within the SDP. The design coordination process also interfaces with all the processes that include service design activity. Key process interfaces include: • Service portfolio management This process provides design coordination with the service charter and all associated documentation such as business requirements, requirements for service utility and warranty (including service options), risks and priorities. • Change management This process produces change requests (formal communications requesting the addition, modification or removal of something in our live environment that we have chosen to control with change management). Design coordination and change management should have collaboratively defined policies and consistent practices for the design work associated with changes. Some changes will be of a scope that they will go through the service strategy stage and service portfolio management process, while others may come to design coordination directly from change management. Design coordination provides status information on design milestones that relate to changes. Change management provides details of authorized changes from which detailed service design activity can proceed. Change management also provides authorization at defined points in the service lifecycle, to ensure that required actions have taken place and that quality criteria have been met. Finally, the post-implementation reviews (PIRs) from change management can provide valuable feedback on areas for improvement for design coordination. • Financial management for IT services This process provides details of the value proposition for the new or changed service as well as budgets available. • Business relationship management This process provides design coordination with intelligence and information regarding the business functions required outcomes, customer needs and priorities and serves as the interface with the customer at a strategic level. • Transition planning and support Design coordination provides the SDP to the service transition stage via this process. Transition planning and support carries out the overall planning and coordination for the service transition stage of the service lifecycle, in the same way that design coordination does for the service design stage. These two processes need to be carefully interfaced to ensure consistent overall plans and resource schedules for current and future projects and changes. • Strategy management for IT services This process provides information about the current and evolving service strategy to enable design coordination to ensure that design guidelines and documentation remain aligned with the strategy over time. • Release and deployment management This process manages the planning and execution of individual authorized changes, releases and deployments. Planning and design for release and deployment is carried out during the service design stage of the service lifecycle. Design coordination should ensure that this is integrated with other service design activities and forms part of the overall SDP. • Service validation and testing This process plans and executes tests to ensure that the service matches its design specification and will meet the needs of the business. Planning and designing tests is carried out during the service design stage of the service lifecycle and design coordination should ensure that this is integrated with other service design activities and forms part of the overall SDP. • Change evaluation This process determines the performance of a service change. This includes evaluation of the service design to ensure it is able to meet the intended requirements. Design coordination should be properly interfaced with change evaluation to ensure that the required resources are available to assist in evaluation of changes. • Service level management Adherence to the standards and practices developed by design coordination for successful service design is critical for this process. Service level management is responsible for defining and agreeing the service level requirements for new or changed services, which must be done in a consistent manner according to practices developed cooperatively with design coordination. Activities of these two processes should be carefully integrated with service level management activity, focusing primarily on the warranty levels that are required in the solution design and design coordination activities. This should ensure that all parts of the service solution design and SDP are appropriately addressed. • Availability, capacity, IT service continuity and information security management processes Each of these processes is actively involved in service design and must perform these design activities consistently, according to practices developed cooperatively with design coordination. • Supplier management In order to ensure that the contributions of suppliers to design activities are properly managed, this process must collaborate with design coordination to develop consistent and reliable practices in this area. Supplier management will then take the lead in building these practices into supplier contracts and agreements as appropriate and then managing the suppliers and their performance during service design, with the assistance of design coordination. Next, we will discuss about IT Service Management.

1.15 IT Service Management

Service Management is defined as “a set of specialized organizational capabilities for providing value to customers in the form of services.” The capabilities take the form of functions and processes for managing services over a lifecycle, with specializations in strategy, design, transition, operation, and continual improvement. The capabilities represent a service organization’s capacity, competency, and confidence for action. The act of transforming resources into valuable services is at the core of Service Management. Without these capabilities, a service organization is merely a bundle of resources that by itself has relatively low intrinsic value for customers. Service Management, however, is more than just a set of capabilities. It is also a professional practice supported by an extensive body of knowledge, experience and skills. A global community of individuals and organizations in the public and private sectors fosters its growth and maturity. Formal plans exist for the education, training, and certification of practicing organizations and individuals influence its quality. Industry best practices, academic research, and formal standards contribute to its intellectual capital and draw from it. The origins of Service Management are in traditional service businesses such as airlines, banks, hotels, and phone companies. Its practice has grown with the adoption by IT organizations of a service-oriented approach to managing IT applications, infrastructure, and processes. Solutions to business problems and support for business models, strategies, and operations are increasing in the form of services. The popularity of shared services and outsourcing has contributed to the increase in the number of organizations who are service providers, including internal organizational units. This, in turn, has strengthened the practice of Service Management and at the same time imposed greater challenges upon it. Let us understand the concepts of service and value in the next slide.

1.16 Concept of Service and Value - Definition of a Service

Service are a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. Outcomes are possible from the performance of tasks and are limited by the presence of certain constraints. Broadly speaking, services facilitate outcomes by enhancing the performance and by reducing the grip of constraints. The result is an increase in the possibility of desired outcomes. Some examples of services include the Service Desk, e-mail, break or fix, video conferencing etc. Each of these services should create value for stakeholders and customers through proper utility and warranty. From the customer’s perspective, value consists of two primary elements: utility or fitness for purpose and warranty or fitness for use. Utility is perceived by the customer from the attributes of the service that have a positive effect on the performance of tasks associated with desired outcomes. Removal or relaxation of constraints on performance is also perceived as a positive effect. Warranty is derived from the positive effect being available when needed, in sufficient capacity or magnitude, and dependably in terms of continuity and security. Utility is what the customer gets, and warranty is how it is delivered. Customers cannot benefit from something that is fit for purpose but not fit for use, and vice versa. It is useful to separate the logic of utility from the logic of warranty for the purpose of design, development and improvement. Considering all the separate controllable inputs allows for a wider range of solutions to the problem of creating, maintaining and increasing value. Next, let us understand the economic value of a service.

1.17 Economic Value of a Service

Calculating the economic value of a service can sometimes be straightforward in financial terms. In other instances, however, it is harder to quantify the value although it may still be possible to quality it. Value is defined not only strictly in terms of the customer’s business outcomes: it is also highly dependent on the customer’s perceptions. The value of a service takes on many forms, and customers have preferences influenced by their perceptions. Definition and differentiation of value is in the customer’s mind. The more intangible the value, the more important the definitions and differentiation become. Customers are reluctant to buy when there is ambiguity in the cause-and-effect relationship between the utilization of a service and the realization of benefits. It is incumbent on providers to demonstrate value, influence perceptions, and respond to preferences. Perceptions of value are influenced by expectations. Customers have reference values on which they base their perceptions of added value from a service. The reference value may be vaguely defined or based on hard facts. An example of reference value is the baseline that customers maintain on the cost of in-house functions or services. What matters is that it is important for the service provider to understand and get a sense of what this reference value is. This may be obtained through extensive dialogue with the customer, prior experience with the same or a similar customer, or through research and analysis available in the market. The economic value of the service is the sum of this reference value and the net difference in value the customer associates with the offered service (refer to the figure). Positive difference comes from the utility and warranty of the service . Negative difference comes from losses suffered by the customer from utilizing the service due to poor quality or hidden costs. As stated earlier, value is defined strictly in the context of business outcomes. Focus on business outcomes over everything else is a critical advance in outlook for many service providers. It represents a shift of emphasis from efficient utilization of resources to the effective realization of outcomes. Customers do not buy services; they buy the fulfillment of particular needs. This distinction explains the frequent disconnection between IT organizations and the businesses they serve. What the customer values is frequently different from what the IT organization believes it provides. In the next slide we will discuss about the combined effect of utility and warranty.

1.18 Combined Effects of Utility and Warranty

Value creation is the combined effect of utility and warranty. Value for customers can be increased by either of the two factors. Both are necessary: neither is sufficient by itself. Each should be considered as a separate factor of value creation. The ability to deliver a certain level of warranty to customers by itself is a basis of competitive advantage for service providers. This is particularly true where services are commoditized or standardized. In such cases, it is hard to differentiate value largely in terms of utility for customers. When customers have a choice between service providers whose services provide more or less the same utility but different levels of warranty, then they prefer the greater certainty in the support of business outcomes. The guidance provided in the Service Design, Service Transition, and Service Operation processes is useful in this strategic context. Service Design processes provide new and improved designs delivering better utility or better warranty. Service Transition processes ensure design improvements are directed into Service Operation while minimizing costs and risks. Service Operation processes inject the new value propositions into the customer’s business by delivering higher levels of utility and warranty. The processes of Continual Service Improvement coordinate the flow of knowledge between the processes and provide feedback throughout the lifecycle. Moving on, let us understand how service operation is value to business in the next slide.

1.19 Value to the Business - Monitor and Measure

Service Operation is the phase of the Service Delivery lifecycle where the actual delivery of service happens. The four basic reasons to monitor and measure lead to three key questions: “Why are we monitoring and measuring?” “When do we stop?” and “Is anyone using the data?” To answer these questions, it is important to identify which of the above reasons is driving the measurement effort. Too often, we continue to measure long after the need has passed. Every time you produce a report you should ask: “do we still need this?” It will be important to sift through large amounts of raw data before synthesizing the right information. This information must then be analyzed and studied, but against what? This is where the different layers of management come in: strategic, tactical and operational, each with their own goals, objectives, critical success factors (CSFs) and KPIs – all of which must be aligned and supportive of each other but , more importantly, aligned with the goals and objectives of the business. The ability to derive any meaningful information from the data collected depends not only on the maturity of the processes but also on the level of maturity of the services provided by IT. Thus it provides value to the business by validating previous decisions. It helps to set direction for activities in order to meet set targets which are the most prevalent reasons for monitoring and measuring. Service Operation as a phase helps to justify, with factual evidence or proof, that a course of action is required In the next slide we learn about process.

1.20 Process

What is a Process? A process can be defined as a structured set of activities designed to accomplish a specific objective. A process takes one or more inputs and turns them into defined output. A process includes all of the roles, responsibilities, tools and management controls required to reliably deliver the outputs. A process may also define or revise policies, standards, guidelines, activities, processes, procedures and work instructions if they are needed. The diagram on the slide shows the generic process diagram, with process inputs on the left, the process itself in the center and the process outputs on the right. Every process requires process enablers and is regulated by a control mechanism. Let us understand the terms shown in the process diagram individually. Process enablers are the process assets which includes Process Resources and Process Capabilities Process control can be defined as: The activity of planning and regulating a process, with the objective of performing a process in an efficient and consistent manner. Processes, once defined, should be documented and controlled; once under control, they can be repeated and become manageable. Degrees of control over processes can define, and then process measurement and metrics can be built- in to the process to control and improve the process as illustrated. Process control includes Process Policy, Process Owner, Process Documentation, Process Objective and Process Feedback The generic process elements show that data is the input of the process, and when it is processed it results in the output and the outcome is measured and reviewed. A process is always organized around a set of objectives. The main outputs from the process should be driven by the objectives and should always include process measurements (metrics), reports and process improvement. Each process should be owned by a process owner who is responsible for the process, its improvement, and for ensuring that the process meets its objectives. The objectives of any IT process should be defined in measurable terms and should be expressed in terms of business benefits and underpinning business strategy and goals. The output produced by a process has to conform to operational norms that are derived from business objectives. If products conform to the set norm, the process can be considered effective (because it can be repeated, measured and managed). If the activities are carried out with a minimum use of resources, the process can also be considered efficient. Process analysis, results and metrics should be incorporated in regular management reports and process improvements. Let’s put all this together and define process in the next slide.

1.21 Organizing IT Service Management - Process Definition

A process is a set of coordinated activities combining and implementing resources and capabilities in order to produce an outcome, which, directly or indirectly, creates value for an external customer or stakeholder. Processes that provide transformation towards a goal, and utilize feedback for self-reinforcing and self-corrective action function as closed-loop systems. It is important to consider the entire process or how one process fits into another. In the next slide we will learn about the characteristics of a process.

1.22 Characteristics of a Process

Every Process should have certain characteristics. • Every process should be measurable. This characteristic actually helps us to understand the quality of the process. • Every process should deliver specific results. The reason a process exists is to deliver a specific result. The result must be individually identifiable and countable. While we can count changes, it is impossible to count how many service desks were completed. • Every process delivers its primary results to a customer or stakeholder. They may be internal or external to the organization but the process must meet their expectations. • Lastly every process should respond to a specific event. While a process may be ongoing or iterative, it should be traceable to a specific trigger. Let us now proceed to look at the Organization Structure in the next slide.

1.23 Organizing IT Service Management - Organization Structure

In an organization’s structure, it is important to align all contributors to the use of common terms with the same meaning. ITIL, therefore, defines concepts of Function, Roles, Groups, Team, Department and Division when it comes to an organization’s structure. First that comes in this picture is Function. A function is a logical concept that refers to the people and automated measures that execute a defined process, an activity or a combination of processes or activities. In larger organizations a function may be broken out and performed by several departments, teams and groups, or it may be embodied within a single organizational unit (e.g, Service Desk). Next is Role. A role refers to a set of connected behaviors or actions that are performed by a person, team or group in a specific context. For example, a technical management department can perform the role of Problem Management when diagnosing the root cause of Incidents. This same department could also be expected to play several other roles at different times, e.g, they may assess the impact of changes (Change Management role), manage the performance of devices under their control (Capacity Management role), etc. The scope of their role and what triggers them to play that role are defined by the relevant process. A group is a number of people who are similar in some way. In this book, groups refer to people who perform similar activities, even though they may work on different technology or report into different organizational structures or even in different companies. Groups are usually not formal organizational structures, but are very useful in defining common processes across the organization –e.g; ensuring that all people who resolve incidents complete the Incident Record (“close the ticket’) in the same way. A team is a more formal type of group. These are people who work together to achieve a common objective, but not necessarily in the same organizational structure. Teams are useful for collaboration, or for dealing with a situation of a temporary or transitional nature. Examples of teams include project teams, application development teams (often consisting of people from several different business units), and Incident or Problem resolution teams. Departments are formal organizational structures which exist to perform a specific set of defined activities on ongoing basis. Departments have a hierarchical reporting structure with managers who are usually responsible for the execution of the activities, and also for day-to-day management of the staff in the department. A division refers to a number of departments that have been grouped together, often by geography or product line. A division is normally self-contained and is able to plan and execute all activities in a supply chain. Before we proceed to the next learning unit which focuses on the Capacity Management process, let us quickly summarize and do not miss on the quiz section.

1.24 Summary

In this learning unit the topics that we covered so far were on Service design, PPO and the process involved within, Design co-ordination and IT service management with process and its characteristics and lastly on Organizing IT service management.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*