3.1.1 Service Strategy

Service strategy is at the core of IT services. It is the heart of service management. The main intent of ITIL and IT service management is to create value for customers. The value creation starts at the service strategy lifecycle phase.

In this phase, the question “Why do it?” is posed before the question “How to do it?” The core intent of this phase is to develop a strategy and create services that add value to customers. In order for the service provider organization to flourish financially, everything must be business as usual at the end of the day.

Suppose you find a gadget online that prepares noodles using flour. And, you are in a country where noodles are found in every shelf in the market, including the ones made from exotic grains. Plus, finances don’t justify preparing your own noodles when you compute the gadget’s cost and the raw materials needed (not to mention the time that is spent). Would it add value to create noodles on your own or just buy some? There is a good likelihood that this gadget would flop in the market. Why? The strategy is all wrong. The company that manufactured it didn’t spend time finding out what creates value for the customer and what the customer really needs. Perhaps a gadget to shred vegetables would’ve been a better gadget to launch!

The most important aspect of service strategy is to understand the customer, identify customer’s needs, and fill those voids. If the provider can do this, even a dim-witted service or product would take off exponentially, until someone else finds a competing service or a product to counter yours.

To explain with another non-IT example, let’s say that a landowner identifies a location in a popular neighborhood that lacks a decent mall in the vicinity. Building one would be like striking gold; you have customers waiting to lap up what you have to offer once it is built. This move can potentially be termed as a successful strategy.

Specifically, with ITIL, service strategy’s role is to provide guidance on creating value through IT services. The idea is to introduce services that has the potential to succeed, and garner market.

3.1.2 Service Design

At the end of the service strategy lifecycle phase, smart heads (read: leadership) have thought over and have provided direction and guidance on which services to offer. The outcome of the service strategy is like the idea that an entrepreneur comes up with. Whether the idea would come to fruition will become known in time.

The service design lifecycle phase answers the question “How do I do it?” It takes the idea and comes up with solutions and designs that give wings to the ideation process set forth in the previous phase.

The success of a service depends primarily on the service design phase. While strategy plays an initial part, the solution to make it happen is equally important.

Tablet computers have existed for a long time. My earliest memory of it was the Palm Pilot in the 1990s, and I started using Windows-based tablet PCs in the early 2000s. They were commonly called PDAs (personal digital assistants) . But it was not until the introduction of iPads in 2010 that led to an explosion in the demand for the touch portable computing devices. They stepped in and became synonymous with the tablet computers.

What are the differences between an iPad and all the other personal hand-held devices that came prior to it? In my opinion, it is the iPad’s design that made the difference. The strategy was out there, since the 1980s, but the lack of a good design didn’t take the early versions to the pinnacle as you would expect. This is my interpretation of the tablet computer history and its relation to design, others may see it differently. But the key takeaway is to highlight the importance of design. Before I end this topic, I would honorably mention Android tablets, which are competing with the iPads neck to neck. There is nothing better than two good designs fighting for fame on a strong foundation built on wise strategy.

Remember the non-IT example that I used under the service strategy topic? After identifying the location, the landowner will have to hire the best architects to bring the most value money can buy on the land that is most sought after. The architectural designs that the architects come up with become the blueprint that gives insight on paper as to what things would look and feel like once they are realized.

3.1.3 Service Transition

The output of the service design is a set of design documents, which gives you the designs pertaining to all aspects of a service. The next task is to develop the service based on the designs. In the ITIL world, this is called the service transition , where the designs are transitioned into production environments through development, testing, and implementation.

The service transition lifecycle phase answers the question “What do I develop and deploy into production?” To achieve the objectives of service transition, you could either employ service design lifecycle activities, hardware delivery lifecycle (HDLC) activities, or any other framework that delves into building a system/service and deploying it into the intended environment. ITIL is flexible like that, it can integrate seamlessly with any of the frameworks you can throw at it.

Going back to the example earlier in this chapter, there are architectural drawings from the previous design phase. These designs are handed over to a qualified builder to construct the mall as per the architectural designs. The builder constructs the mall in this phase as per the plan and brings it to a state where it could be operationalized. This is exactly the role of the service transition phase.

3.1.4 Service Operations

Service operations is the most popular phase in the ITIL service lifecycle. Reasons are twofold:

1. Operations run for a long time. I am trying to avoid the word infinite here, as there is nothing guaranteed in this world. So, in effect, operations run for a long time, which translates into most service management practitioners working under the service operations lifecycle phase.

2. As the phase runs the maximum amount of time, it has the maximum number of touch points with the customer. Moreover, operations is considered to be the first point of interaction for a customer on a regular basis. (You will find out more about this in Chapter 7.)

Service operations entails maintenance and making sure the services are running as per the plan—status quo is achieved. Under service operations, there is no new development, no deployments, and only maintenance. Some maintenance activities could include health checks, fixing issues when they arise, and ensuring recurring activities are scheduled and run as planned. This will be discussed in detail in Chapter X.

Drawing on the previous example, the mall owner takes possession of the mall, rents out the shops, and sets the ball in motion for it to run smoothly. For it to be operationalized, he needs to hire people who can manage various areas of the mall and employees who can carry out day-to-day tasks, like cleaning, security, marketing, etc. He also needs to set up daily/weekly/monthly/yearly activities to ensure required activities to keep the mall functioning . Examples could be monthly generator checks, security audits, four-hour restroom janitorial services, etc. You get the drift?

By looking at this simple example, you can easily see the activities that are needed in operations. The operations phase in IT service management is a lot more complicated and requires plenty of minds to work out various aspects of it.

3.1.5 Continual Service Improvement

The final phase in ITIL is continual service improvement. While I call it the final phase, it does not necessarily come into play after the service operations phase. If you look at Figure 3-1 closely, you will observe that this phase encircles all of the other four phases. There is meaning to this. This phase takes input from any of the other phases to carry out its process activities. You can also say that it does not fit in the lifecycle phases as it does not roll once the previous phase has completed its delivery. But remember that this is the phase that keeps the ball rolling, the service breathing. You will learn more about this later in this book.

I strongly believe that if something does not grow, it is as good as dead. This is true with our careers, bank accounts, or anything else you might think of, except of course our waists! This concept applies to services too; if they do not improve over time, IT services wither away and something else takes its place. The objective of the continual service improvement (CSI) phase is to identify and implement improvements across the four lifecycle phases; be it improvements in strategies, designs, transition, or operations, CSI is there to help. It is also the smallest phase of all the phases in ITIL.

In keeping with the example, in the fully functional mall, you might have thought that general maintenances should be sufficient for upkeep and ongoing operations. It may be good for a brief period but not for long. Competition heats up with other malls competing with it in terms of amenities, parking availability, and aesthetics, among others. If our mall does not improve in due time, customers are going to lose interest, and sales will start to dwindle. So, to keep up with the growing demands, the mall owner must find ways to make the mall exciting for shopkeepers as well as for customers, perhaps providing space underground for a public transit station, valet parking for certain customers, free high-speed Internet for customers, and installation of moving walkways. These improvements need not happen overnight, it can be a process set over days and months. But the important thing is to keep improving the mall on a regular basis.

3.2.1 Roles vs. Designations

Roles and designations are different. Often, people get confused and believe that one is synonymous with the other, which is not the case. Designations provide you a hierarchy based on your organization’s structure. It places you in the pyramid based on your experience, salary, and maturity. ITIL roles, or any other roles, tell you which activities you will be performing and which areas of ITIL are under your supervision. It does not delve into the seniority of the people performing it. It is up to the organization to map the right designations with the ITIL roles. In many cases, a designation analyst will perform the role of a change manager in a particular organization. In another organization, a designation senior manager could be performing the same role.

So, to conclude, in ITIL, whenever roles are referred to, we are referring to the activities that a person will be performing as a part of this role and not the person’s designation.

3.2.2 Generic vs. Specific

Every ITIL process brings to the table at least a couple of roles. So it brings plenty of employment opportunities, plus, customers would be happier dealing with people with the right skill set and with the organization that has clarity over people owning and managing respective areas. So with 26 processes in the pipeline, you are looking at over 50 different roles at a minimum.

I am not going to define each and every role in this section. Here I will provide insight into the generic roles that can be slotted against respective processes to define specific roles.

For example, the generic role for somebody who owns the process is a process owner, and the person managing the activities is the process manager. For these roles to be defined specifically for a particular process, say the incident management process , we need to define the specific role as that of an incident management process owner or an incident manager. At a higher level, the generic role will define what a process owner does, and specifically at the process scope, we define the objectives and responsibilities of an incident management process owner.

3.2.3 Generic Role: Service Owner

In Chapter 2, I explained what a service is. So, this service, which provides value to the customer, must have an owner to ensure somebody has accountability. The person who owns the service, end to end, and the person without whose consent no changes would be done is the service owner.

In the mall example, the mall owner is accountable for the shopkeepers and the customers. He owns the place, so he puts his signature across all changes being made to it, in other words, he approves enhancements and modifications and decommissions if any. He is the service owner in ITIL terminology.

3.2.4 Generic Role: Process Owner

I also introduced the concept of a process Chapter 2. A process is a set of coordinated activities that exist to meet the defined objectives. This process, or the series of coordinated activities, needs an owner, someone who has a finger on the pulse to check if the process is fit for the purpose, and that it is subjected to continuous improvements. He is the process owner. He will be accountable for the process deliveries, be it in terms of effectiveness or efficiency.

In the mall example, there will be several processes defined and implemented. One such process is the process to maintain diesel generators. The maintenance process could go something like this: weekly general checks on Sundays at 10 P.M. Detailed monthly checks on the first Sunday of a month at 11 P.M. Checks are done based on a checklist. If minor repairs are identified, they are carried out during the maintenance window. If a major repair is identified, a suitable window is arranged, all necessary resources are mobilized and repairs are carried out by a specialist team. This diesel generator process cannot be orphaned. It needs somebody to own it and ensure that it is meeting its objectives: no outages owing to the generators.

3.2.5 Generic Role: Process Manager

We know what a process is and who the owner is. It is unlikely that an owner will actually manage things on his own. He will hire people who can manage the process for him. Process managers ensure that the processes run as per its design and achieve what it’s meant to. Since they are close to the works, they are in a good position to suggest improvements to the process owner. A decision to accept or reject the suggestions is made by the process owner.

A process manager is accountable for the operational management of the process, which defines coordinating activities between various parties; monitoring, developing, and publishing reports; and, as mentioned earlier, identifying improvement opportunities.

In the diesel generator maintenance process, the process owner hires an electrical engineer to manage the maintenance activities and to report on the outcomes. The maintenance manager is responsible for ensuring that technicians involved have the right skill set and are following the right set of instructions in carrying out the maintenance activities. If the manager finds that the weekly checks are not adding value, he can suggest to the process owner to shelve the weekly checks and set it for every two weeks. As mentioned earlier, the decision to make the checks every two weeks is made by the owner, not the manager.

3.2.6 Generic Role: Process Practitioner

Anyone who plays a part in the process is a process practitioner. This may be the manager or the owner, or someone who may not be part of the process hierarchy. To rephrase, people who are responsible for carrying out one or more activities in a particular process are process practitioners.

In the generator maintenance process, technicians have the responsibility to check the generators based on a checklist. They are process practitioners. It is also likely that the technician is a process practitioner for multiple processes, depending on the number of processes he is acting on. For example, he could also be responsible for electrical maintenance, electrical repairs, and elevator maintenance, thus being a process practitioner in each of these processes.

3.3.1 Understanding RACI with an Example

Here is an example of how a RACI looks. It has activities to be performed as a part of a process in several rows. Those who would play a role in the process figure in the column. We get a matrix by putting the activities and the roles together, as shown in Figure 3-3.

Figure 3-3. RACI for maintenance activities in the mall example

In the example, for the activity, Schedule maintenance activities, this is owned and performed by the maintenance manager (AR represents Accountability and Responsibility in the respective cell). So, both the accountability and responsibility lie with him. For this activity, he is consulting (represented by C) with the mall owner on suitable dates, and informing (represented by I) the maintenance engineer on the maintenance schedule.

Let’s look at the final activity: fix issues with diesel generator. In this activity, the accountability lies with the maintenance manager, but the person performing the fixing is the maintenance engineer. The engineer consults with the manager regarding this activity, as the manager is an experienced hand in diesel generators. The mall owner is merely informed on this activity.

3.3.2 Ground Rules on RACI Matrix

Developing a good RACI matrix takes experience and good insight into the activities on hand. However, there are a few ground rules that will aid you in your RACI creation endeavors:

1. For every activity, you can have only one person accountable.

2. Responsible, consulted, and informed can be spread across multiple roles, although I have not illustrated this in the example.

3. A single role can don various hats, such as accountable and responsible for the Sponsor maintenance activities by the mall owner.

4. Accountable and responsible are mandatory for every single activity.

5. Consulted and informed are optional, if you are not informing anyone of an activity, you may not have the informed role for the particular activity, Sponsor maintenance activities is an example.

6. Identify and document as many activities as possible in the RACI matrix, as long as the activities have specific deliverables coming from it.