People are Important to Service Design

One of my favorite sets of analogies to use in class is food, the making of  food or restaurant operations. We make what we eat by pulling together ingredients into recipes. In the same way, we design services. We use the elements of services combined into the five aspects of design (solutions, tools, architectures, process and measurement) to produce the Service Design Package (SDP).

When we think about designing services, we must remember it takes a number of elements. ITIL v3 says there are four elements of service design:

1. People
2. Process
3. Products
4. Partners

I like to think of these elements as the “ingredients” of a service. The most important “ingredient” in any service is the “people”. We can have effective processes, efficient products, and loyal partners, but without people the service will get nowhere.

 

People are the elements that make the value for the customer truly possible. Processes do not execute themselves, products do not spontaneously build and partners are not engaged out of nothing. It takes people working together to strategize, design, transition, operate and improve a service.

So how do we ensure that the people-element of services is truly engaged? Here are some ideas:

1.  Identify roles and responsibilities early in the design of a service and tweak or improve them as the design gets more complete
2. Develop and execute a parallel Organizational Change Management (OCM) effort to occur alongside your service design
3. Look for and incorporate feedback from stakeholders of services from the beginning of design not as an afterthought
4. Identify measurements and metrics that encourage a culture of improvement, not a culture of punishment for failure
5. Learn and apply some basic human interaction good practices within your organization (listening, interpersonal relationships, communications, work-life balance for example)

Most important is the need to see people as both the glue that holds a service together and the engine that drives the delivery of value. Do not simply say “people are your most important asset”, rather act and behave as if they really are your most important asset. 

 

Restaurants recognize that the food can be great, the atmosphere inviting and the suppliers timely, but without great staff the customers will not have a truly enjoyable experience. So put people before processes, products, and partners and you will reap the benefits!

ITIL Technology Lifecycle Management

The Professor has been asked, “Does ITIL address Technology Lifecycle management?”

In version 2 of ITIL, the ICT Infrastructure Management book focused on technology management.  This is still a good resource, although availability of the publication may now be very limited.   In Version 3, the same information is spread across the lifecycle - most heavily in Service Design, Service Transition and Service Operation. 

There are a couple of updates in ITIL Version 3 for technology management.   Configuration Management is now "Service Asset and Configuration Management" so that Asset Management and Configuration Management are integrated.   Service Design now defines a Technical Service Catalog to acknowledge underpinning technical services that are critical elements of business services.  ITIL also includes a Technical Management function as the custodian of technical expertise. While the Technical Management function performs most of it's work in Service Operation, it is actively involved in all stages of the lifecycle.

I would also direct our followers to the Microsoft Operations Framework (MOF).  Written by Microsoft as a Solution Accelerator that is heavily aligned with ITIL, MOF take a more practical approach to managing all of the elements of services including including the underlying technology (remember what Microsoft's primary business is!).   MOF is also lifecycle-based and defines Management Reviews at specific points in the service lifecycle. 

MOF is available free of charge at www.microsoft.com/mof and there is a MOF Foundation course.  Microsoft has also provided valuable job aids with the MOF materials.

All in all, services have to be managed end-to-end.  While the technologies are critical, it is very important to integrate Technology Management into the supply chain leading to effective and efficient business services.

Who is the Change Initiator

The Professor has been asked to clarify the role of the "change initiator". 

The “change initiator” is the individual or group that is requesting the change. Change initiators could be users, suppliers or IT staff – depending on the nature of the proposed change. It is the change initiator’s responsibility to justify the reasons for making the change. 

However, since the change initiator may not understand all of the risks associated with a seemingly innocuous change, some type of impact assessment should occur.  The assessment could be very simple and quick - or extensive- based on the scope of the change and business processes that are potentially affected.

The change authority (CAB, Steering Committee, local CABs, etc.) assesses the impact of the propose change and determines if the change is necessary or beneficial.  Impact could be negative or positive and should consider cost/benefit, resources required or risk. While ITIL does not assign a specific role to the “change assessor”, the role is an extension of the CAB.   You can also authorize experts to assess and approve technical changes  – however be wary of relying too heavily on a single person to make the call.   They may develop "tunnel vision" and only consider risk from within their own domain.  Potential residual risks may be overlooked.

One individual can serve multiple roles.  Change assessors may also be responsible for ultimately performing or implementing the change.  ITIL calls that role a “release analyst”. 


Change models are particularly helpful to change initiators, change authorities and release analyst.  You can create models for common types of changes (from low risk to high risk).  The model will pre-define the steps and procedures needed to request, assess and implement that type of change.

Application Management Lifecycle

In a previous Blog I spoke to Application Management from the point of view that they do not actually develop the application but manage it throughout its entire lifecycle. This is done through the Application Management Lifecycle along with Operational Models.

Operational Models are the specifications of the operational environment in which the application will run after it has been deployed. This model is used to simulate and evaluate the live environment during the Design and Transition stages. It also ensures that proper environmental requirements and sizing can be documented and understood by all groups or teams involved with application development and management.

Many of you are familiar with “Software Lifecycle (SLC) and “Software Development Lifecycle” (SDLC). These are use by application development and project teams to manage the designing, building, testing, deployment and support of applications.

From an ITIL perspective the Application Management Lifecycle looks at the overall management of applications as part of the IT Services. It consists of six phases and takes a much more holistic view on:

•  Requirements: How requirements are gathered. There are six: Functional ,Manageability, Usability, Architectural, Interface, Service Level
• Design: How those requirements are translated into design specifications. This is the design of the application and the operational model. Considerations for both application and system architecture are strongly related and must be aligned at this phase
• Build: Both the application and the operational model are built, tested and readied for deployment. Testing is part of this and the deployment phases. It is used to validate both the activities and the output of both phases.
• Deploy: How the application and the operational model are incorporated into the existing IT environment.
• Operate: How the service is delivered and the performance of the application is monitored and measured against established Service Levels and Key Performance Indicators (KPI’s).
• Optimize: How the results from performance measurements are analyzed and then acted on. Two Critical Success Factors (CSF’s) for this phase, are to maintain or improve the Service Levels and to lower costs.

An important fact to remember about the Application Management Lifecycle is that it is circular (Fig 6.5 SO pg130) and that the same application can reside in different phases at the same time. For example, a previous version of an application can be live in operations phase, while the current version may be in the deployment phase, while the future version may be in the design phase of the Application Management lifecycle. For this reason strong version, configuration and release controls should be in place.

Application Management

When I teach ITIL V3 Foundation classes I often have to make the distinction between Application Management which is one of the “Service Operation Functions” and Application Development.

I often begin my discussion by explaining that Application Development is responsible for the actual development and building of applications by the developers. Application Management is responsible for managing applications throughout their lifecycle and is performed by any department, group or team that is involved in managing and supporting operational applications. Additionally the function also plays a role in the design, testing and improvement of applications that form part of IT services.

Application Management plays a key role in all applications whether purchased from a third party manufacturer or developed by in-house staff. During the design stage of the ITIL Lifecycle one of the key decisions made by Application Development is whether to buy or build. After that decision is made Application Management plays dual roles:

• Custodians of technical knowledge and expertise in the managing of all applications. They work alongside of Technical Management to ensure that the knowledge required to design, test, manage and improve IT services is identified, developed and refined.
•  IT also provides the actual resources to support the ITSM Lifecycle. It ensures that resources are effectively trained and deployed to design, build, transition, operate and improve the technology required to deliver and support IT services.

 A “Critical Success Factor” for Application Management is to ensure a balance between the skill level of the resources involved and the cost of those resources. This is accomplished by:

• Providing guidance to IT Operations on how to best implement ongoing operational management of applications done both in Service Design and IT Operations.
• Integration of the Application Management Lifecycle into the ITSM Lifecycle.

This is supported by specific objectives within Application Management and the Application Management Lifecycle which will be discussed in an upcoming Blog.

Service Acceptance Criteria

I have often been asked what value does the Service Acceptance Criteria (SAC) provide?

First let’s understand what the SAC is by definition.

Service Acceptance Criteria: A set of criteria used to ensure that an IT Service meets its functionality and quality requirements and that the IT Service Provider is ready to operate the new IT Service when it has been deployed. This set of criteria is in the form of a formal agreement that an IT Service, Process, Plan or other deliverable is complete, accurate, reliable and meets the specified requirements.

We must understand that all design activities are triggered by changes in business needs or service improvements. In order to design and deliver IT services that meet the changing needs of the customers and the business, we must ensure that the contents of the Service Acceptance Criteria are incorporated and the required achievements are planned into the initial design.

The Service Acceptance Criteria is the document that will ensure the Service Provider is ready to deliver the new service by answering the following criteria:

• Has the go live date been agreed to with all parties?
• Has the deployment project and schedule been agreed to and made public to all stakeholders?
• Have all SLR/SLA’s been reviewed, revised and agreed to with all stakeholders?
• Has the Service Catalogue/Portfolio been updated and all appropriate relationships established within the Configuration Management System?
• Have all users been identified/approved and appropriate accounts created for them?
• Can all SLR/SLA targets be monitored, measured, reported and reviewed?
• Can performance and capacity targets be measured and incorporated into the Capacity Plan?
• Have incident and problem categories and processes been reviewed and revised for the new service?
• Has appropriate technical support documentation been provided and accepted by Incident, Problem and all IT support teams?
• Have all users been trained and user documentation been supplied and accepted?
• Have appropriate business managers signed off acceptance of the new service?

With this documented criteria in hand we can insure that the Service Provider will meet the agreed needs of the customer and the business. It will insure that availability, capacity, security and continuity can be assured and thereby deliver value to the business.