Organizing for Service Design Tutorial

5.1 Organizing for Service Design

Organising for Service Design Welcome to Learning Unit 5 of ITIL Lifecycle Intermediate Service Design Certification Course by Simplilearn! The maturity of an organisation is sometimes reflected through the performance of the people. A clear organisation structure with well-defined roles and responsibilities enable people within the organisation to take timely decisions, execute their activities with confidence and ensure seamless flow of activities. RACI model is a key tool for establishing and communicating the authorities and responsibilities of each role with respect process activities and organisation activities required to be performed by them. This learning unit covers all these important topics. Let’s look into the syllabus that will be covered in this unit.

5.2 Learning Unit 1: Syllabus

Syllabus The objectives of this learning unit are to cover: • The knowledge, interpretation and analysis of service design principles, techniques and relationships and their application to the design of effective service solutions. • How to design, implement and populate a RACI diagram for any process that is within the scope of IT service management. • The service design roles and responsibilities, where and how they are used and how a service design organisation would be structured to use these roles. Let’s learn about RACI in the next slide.

5.3 RACI

RACI A key element of process designing is detailing the roles and responsibilities as clearly as possible. As services, processes and their component activities run through an entire organisation, the individual activities should be clearly mapped to well-defined roles. • RACI model is an effective way of defining the roles and responsibilities in relation to processes and activities. It provides a compact, concise, easy method of tracking who does what in each process and enables decisions to be made quickly and with confidence. The acronym RACI stands for: • Responsible: The person or people responsible for getting the job done. • Accountable: The person who has ownership of quality and the end result of the activity. Only one person can be accountable for each task. • Consulted: The people who are consulted and whose opinions are sought – especially subject matter experts and senior management. • Informed: The people who are kept up-to-date on progress of the activities.

5.4 RACI

RACI • Some organisations have added more roles and have come up with some variations of RACI. One such variation is RACI-VS. • The additional ‘V’ stands for ‘Verifies’: The person or group that checks whether the acceptance criteria have been met; and • ‘S’ stands for ‘Signs off’: The person who approves the verified decision and authorises the product hand-off. This could be the Accountable person also. • Another Variation: RASCI • Where the additional ‘S’ stands for ‘Supportive’: The person or group that provides additional resources to conduct the work or plays a supportive role in implementation. Let’s look into RACI matrix in the next slide.

5.5 RACI Matrix

A sample RACI matrix is shown in this slide. The row headings show the activities and the column headings show the roles. For each activity you may easily identify who is accountable, who is responsible and who all need to be consulted and informed. It may be observed that while there may be multiple people who may be responsible for executing the activity or consulted for more inputs, suggestion or guidance; and more than one person may need to be kept informed about the progress or status of the activity; only one person can be accountable for the activity. Thus you find only one ‘A’ for each activity. In the next slide we will look into functional role analysis based on the RACI.

5.6 Fuctional Role Analysis based on the RACI

Functional Role Analysis based on the RACI Before formally publishing the RACI matrix, it is important to analyse the RACI chart to identify any weaknesses or areas of improvement both from role and activity perspectives. It generally involves finding answers to the following questions: • Are there too many Accountable? • Are duties segregated properly? • Should someone else be accountable for some of these activities? • Is this causing a bottleneck in some areas that will delay decisions? • Are there too many Responsible? • Is this too much for one function? • Is there no empty space? • Does this role need to be involved in so many tasks? • Does the type or degree of participation fit this role’s qualifications? Answers to these questions help in fine-tuning the matrix or correcting any wrong assignment of roles and responsibilities. It is important that the final RACI chart should be documented, agreed by all concerned and published. This ensures making people aware of their authorities and responsibilities and enhances the efficiency of the overall process performance. Let’s look into the functions in the next slide.

5.7 Functions

Functions Organisation structure depends on various factors like size and location of the organisation, complexity of technology used, culture and financial situation of the organisation. Functions may be named in different ways in different organisations. We shall now discuss some important concepts relating to ‘Functions’. • First the definition of ‘Function’. A function is a team or group of people and the tools or other resources they use to carry out one or more processes or activities. The people within the group perform similar or related activities and may use a common set of tools. • In larger organisations, a function may be broken down and performed by several departments, teams and groups, or it may be embodied within a single organisational unit. It is always better to organise teams into logical units based on activities performed so as to enhance productivity and enable performance measurement. • In smaller organisations, one person or group can perform multiple functions – for example a technical management department could also incorporate the service desk function.

5.8 Functions Continued...

Functions • An organisation will need to clearly define the roles and responsibilities required to undertake the processes and activities. The best way to achieve this is to create a RACI matrix and publish the same to all concerned. • These roles will need to be assigned to individuals, and an appropriate organisational structure of teams, groups or functions established and managed. This ensures manageability, measurability and control at appropriate level. It also enables faster decision making and management of escalations. • ITIL Service Design guidance does not define any specific functions of its own, but it does rely on the technical and application management functions described in ITIL Service Operation. The technical and application management functions provide resources and expertise across all lifecycle stages including the Service Design stage. In the next slide we shall look into the alignment with application development.

5.9 Alignment with application development

Alignment with application development An organisation may buy required software application or develop them internally. In some cases, even if the software applications are purchased, there may be a lot of effort involved in configuring and customising the applications to meet the organisational requirements. • If an application development function exists, this team will focus on building functionality – that is, the utility – required by the business. It is important to ensure that inputs are sought from other functions like application management, technical management, IT operations management and service desk from an service operation perspective and these be incorporated in the design and development activities. • Most application development work is performed as part of a project where the focus is on delivering specific units of work to specification, on time and within budget. Project budgets usually take care of the development costs. However, it is important to allocate funds for operational and improvement activities as well. Also, the application development function may adopt a software development lifecycle to develop the applications. It is critical that this be integrated with the overall service lifecycle as applications form an important component of IT services provided to business and customers. We will next look into alignment with project management in the coming slide.

5.10 Alignment with project management

Alignment with project management • Project Management Office could be another functional unit that may exist in an organisation. The purpose of project management office is to define and maintain the project management standards and to manage and allocate resources for projects planned or in progress. This function will also provide value when project portfolios are integrated with service portfolio management. • The project management function usually leverages the principles of one or more of the recognised project management methodologies like: • PMBoK – Project Management Body of Knowledge by Project Management Institute; or • PRINCE2 – Projects in controlled environments by the Office of Government Commerce. • The project teams are normally actively involved in the work of the service design and service transition stages of the lifecycle, as well as during any other temporary endeavours like improvement initiatives. Let’s look into the example of service design organisation structure in small organisations in the next slide.

5.11 Example of service design organization structure(small organization)

Example of service design organisation structure (small organisation) • The diagram on this slide represents the Service Design Organisation Structure for a small organisation. Some general characteristics of this structure are: • The roles of process owner and process manager are likely to be combined. In this case, the design cordination process owner, process manager and process practioner roles rest with the Service Design Manager. • One person may be handling or responsible for several roles. For example, in this structure, the role of service level manager is also the supplier management process owner as well. • It is important to ensure not to combine roles where there is governance or compliance requirements or where there is a conflict of responsibilities involved. Let’s look into the example of service design organisation structure in large organisations in the next slide.?

5.12 Example of service design organization structure(large organization)

Example of service design organisation structure (large organisation) We shall now look at an example of Service Design Organisation Structure for a large organisation. You may note that : • There is a central Headquarters organisation which constitutes all process owners, and the service design team. • There is a separate Service Management office, a Project Management Office and a global programmes group at the Headquarters. • Each geographical region has its own process managers and practionioners. • Good communication and coordination are very essential in this type of structure. The responsibilities must be clearly demarcated between global and regional teams to avoid gaps, duplication and rework. In the next slide we shall look into service design roles.

5.13 Service Design Roles

Service Design Roles The following are some of the important roles relating to Service Design Stage and processes. • Generic Service Owner • Generic Process Owner • Design Coordination Process Manager • IT Planner • IT Designer/Architect • Service Catalogue Management Process Manager • Service Level Management Process Manager • Availability Management Process Manager • IT Service Continuity Management Process Manager • Capacity Management Process Manager • Security Management Process Manager • Supplier Management Process Manager Please note that all the Service Design related process manager roles have been discussed in Learning Unit – 3 as part of discussion of each process. We shall now cover the remaining ones in the following slides.

5.14 Generic Service Owner

Generic Service Owner Let us start with the generic service owner role. The service owner is accountable for the delivery of a specific IT service. He is also responsible to the customer for the initiation, transition and on-going maintenance and support of the service and accountable to the IT director for the delivery of the service. The responsibilities of a service owner include: • Ensuring that the on-going service delivery and support meet agreed customer requirements • Working with business relationship management to understand and translate customer requirements into activities and to ensure that the service provider can meet those requirements • Ensuring consistent and appropriate communication with customers for service-related enquiries and issues • Assisting in defining service models and in assessing the impact of new services or changes to existing services through the service portfolio management process • Identifying opportunities for service improvements, logging them in CSI register, discussing these with the customer and raising Requests For Changes as appropriate • Liaising with the appropriate process owners throughout the service lifecycle • Soliciting required data, statistics and reports for analysis and to facilitate effective service monitoring and performance • Representing the service across the organisation • Serving as the point of escalation for major incidents relating to the service • Representing the service in change advisory board meetings • Participating in internal service review meetings within IT • Participating in external service review meetings with the business • Ensuring that the service entry in the service catalogue is accurate and is maintained • Participating in negotiating service level agreements and operational level agreements relating to the service • Working with the CSI manager to review and prioritise improvements in the CSI register • Making improvements to the service Let’s look into Generic Process Owner in the next slide

5.15 Generic Process Owner

Generic Process Owner The process owner is accountable for ensuring that a process is fit for purpose. He ensures that all process activities are carried out and is responsible for: • Sponsoring, designing and change managing the process and its metrics; • Defining the process strategy; • Assisting with process design; • Ensuring that appropriate process documentation is available and current; • Defining appropriate policies and standards to be employed throughout the process; • Periodically auditing the process to ensure compliance to policy and standards; • Communicating process information or changes as appropriate to ensure awareness; • Providing process resources to support activities required throughout the service lifecycle; • Ensuring that process technicians have the required knowledge and required technical and business understanding to deliver the process; • Reviewing opportunities for process enhancements and for improving process efficiency and effectiveness; • Addressing issues with the running of the process; and • Identifying improvement opportunities for inclusion in the Continual Service Improvement register. Let’s learn about IT Planner in the next slide.

5.16 IT Planner

The IT Planner is responsible for the production and coordination of IT plans. Some of the key responsibilities of an IT Planner include: Develop IT plans that are always aligned to meeting the IT requirements of the business Coordinate, measure and review the implementation progress of all IT strategies and plans Produce and maintain the overall set of IT standards, policies, plans and strategies, encompassing all aspects of IT required to support an organisation’s business strategy Recommend policy for the effective use of IT throughout the organisation Review IT costs against budgets and new developments, initiating proposals to change IT plans and strategies where appropriate, in conjunction with Financial Management for IT Services Assuming full responsibility for the management, planning and coordination of IT systems and services Reviewing IT performance with all other areas and initiating any improvements in organisation Investigating major options for providing IT services effectively and efficiently and recommending new innovative solutions Producing feasibility studies, business models, IT models, business cases, statements of requirements and invitations to tender for recommended new IT systems Overseeing and coordinating the programme of planned IT project implementations and changes Let’s learn about IT designer or architect in the next slide.

5.17 IT Designer Architect

IT Designer/Architect An IT designer/architect is responsible for the overall coordination and design of the required technology. The designer/architect should produce a detailed process map that documents all the processes and their high-level interfaces. The other responsibilities of this role include: • Designing secure and resilient technology architectures that meet all the current and anticipated future IT requirements of the organisation • Ensuring that the design of all processes, roles, responsibilities and documentation is regularly reviewed and audited for efficiency, effectiveness and compliance • Designing an appropriate and suitable service portfolio, supporting all activities within the complete service lifecycle • Designing measurement methods and metrics to support the continual improvement of service provision and all supporting processes • Producing and maintaining all aspects of IT specification, including the overall designs, architectures, topologies and configurations of the infrastructure, environment, applications and data, and the design documentation of all IT systems. This should include not just the technology, but also the management systems, processes, information flows and external services • Recommending proactive, innovative IT solutions for the improvement of IT design and operation whenever and wherever possible • Translating logical designs into physical designs, taking account of business requirements, target environments, processes, performance requirements, existing systems and services, and any potential safety-related aspects • Creating and maintaining IT design policies, philosophies and criteria, covering all areas including connectivity, capacity, interfaces, security, resilience, recovery, access and remote access, and ensuring that all new services meet their service levels and targets • Interfacing with designers and planners from external suppliers and service providers, ensuring all external IT services are designed to meet their agreed service levels and targets • Playing a major role in the selection of any new IT infrastructure or technology solutions • Where required, assessing changes for their conformance to the design principles, including attendance at CAB meetings if appropriate. Let’s now look into the summary of this unit in the next slide.

5.18 Summary

In this unit we learned about RACI, i.e., R —“Responsible”, A —“Accountable”, C —“Consulted” and I —“Informed”. We learned how to design, implement and populate RACI. We also understood the service design organisation in terms of small and large organisations. Lastly, we also looked into the service design roles, generic service owner, generic process owner, IT planner and IT design or architect.

  • 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*