Pulling It All Together - CLAP + PMLC

In a series of previous posts, we took a look at various frameworks for bringing valuable IT Services to an Enterprise. Starting with the CLAP Framework, we saw took a look at a basic way of starting with Business Activities and building the necessary Conceptual, Logical & Physical Infrastructures to deliver valuable IT Services.

Next, we saw how to use a tool like the ERRC Canvas to achieve the Enterprise Strategy, by mapping the strategy to goals & objectives. The key function of the canvas is to separate the objectives into four areas: Eliminate, Reduce, Raise & Create. 

Once divided, metric for success are applied, and plans can be created. These plans can be prioritized and dependencies mapped. Getting from Business Strategy to IT Execution is no easy feat - so this post describes a method of execution.

Of course, understanding goals as they relate to Strategy is also very important. We took a look at how to create SMART Goals.

Illustration: CLAP and PMLC Together on One Page

We are now in a position to pull all of those concepts into one diagram, shown above. I have attempted to layer the various concepts together, and embellished them with some extra information, such as when a project can expect to need to engage various roles within the RACI.

Finally, we see three vertical lines which describe a form of IT Governance. In a future post, I will describe the make-up of the ARB/TRB and explain the importance of the Architectural Validation Plan.

The Importance of Process

 

I haven't blogged in some time. Seems life can get overwhelmingly busy at times, and well - it has been some of those times ! I've been spending a lot of time lately working on things that are process-oriented. Seems that when organizations want to define the products and services they sell, they ignore the industry-accepted definition.

According to ITIL, a Service is made up of people, process and technology. All too often, the organization believes that they can simply purchase and implement a tool, and all of their problems will miraculously disappear. I am working with two clients, who are approaching their delivery of a Service differently.

The first client is a large player in the Energy sector. To date, they have eschewed the use of ITIL terms to define their IT Service, as it doesn't readily fit their model for doing business. How could they let IT tell them how to run their business ?

When this client wanted to clean up their IT monitoring systems, they chose to segment the work into business-identifiable Services. They presumed they could buy a tool, and their visibility into their IT Operations would magically improve. They have been profitably in business for decades, so surely their processes and people were fine ?

In examining the first Service, it became apparent that the technology they were employing was actually satisfying 90% of their needs. It seemed the issues came up after the monitoring system alerted to a problem. Multiple service tickets were generated, usually causing a firestorm of activity - usually within the wrong groups ! To exacerbate the issue, the groups weren't communicating. This meant there was almost always a large duplication of troubleshooting effort.

In the case of the first client, the processes which were initiated were the root-cause of their issues. The technology did what it was supposed to do: send an alert when a problem arose. The people simply followed the process and reacted to the alert in a timely fashion. Unfortunately the process didn't allow for communication and co-ordination of their efforts, leading to delays and confusion in the IT personnel.

The second client is a small services company. They are re-building the company from the ground up; I call it going back into startup mode. In so doing, they are examining the services they provide to their clients. From the very basest levels, they want to be able to create repeatable, sustainable & desirable solutions for their clients.

This is being achieved by turning everything they do into a "project", with somebody responsible for managing that project at the helm. Project Management 101 would tell us that the Project Manager is responsible for Resources, Timeline and Budget - does this sound like what a Management Team should be concerned about ? So whether it is a team which is conducting Research and Development on a new physical product, or the Marketing guy working on building a new web-site, everything is a project. This provides visibility into "who ?", "when ?" and "how much ?" questions.

What this also means is that the second client can begin to normalize their Operations. By treating everything like a project, they have a repeatable framework to follow. The standard body of documentation required for every project (Charter, Cost/Benefit Analysis, Project Plan, Work Breakdown Structure and Closeout Report) allows for repeatability. Need a tower built ? Here's the required artifacts. Need a portable antenna installed ? Heres the project plan.

This will allow the client to have very tight control over their operations. This leads to increased productivity of the resources, as well as predictability in their Finance department, in terms of budget and revenue. The Sales and Business Development people can look at an exisiting Project Plan and estimate for themselves roughly how long it should take to complete a project. Further, if they are simply repeating a pre-exisiting project, they can likely provide a pricing quotation on their own.

So in both cases, we are seeing how these two very different clients are approaching their issues by examining the Services they provide. And in so doing, they are recognizing the importance of having well-documented procedures for their people to follow. The technologies they employ are all but irrelevant.

Posted with Blogsy

ITSM - Defining the Service

This is the second part of my series about my client's ITSM project. Previously, we discussed the challenges associated with chasing shiny objects, and believing that the implementation of a product would solve the client's problems. All too often, ITSM projects fail, because the organization fails to differentiate between a Business-Critical Service and an application.

The first step of the project-plan is defining the Service. This means identifying all of the components which participate in the service. By the ITIL definition, a Service is comprised of People, Processes & Technology. Most IT Professionals will look at the Technology components first. Storage, SAN, inter-networking, and server hardware. Later, the applications which make up the Business-Critical application are considered. There can certainly be many applications involved - even indirectly. Consider how important DNS is to most IT applications.

An outstanding deliverable is the information ABOUT the service - it's owner, it's provider, it's consumers and such. These are key to a later Deliverable, when it's time to start identifying the Service Level Objective/Agreement (SLO/SLA). It is important to start defining these early, even if they may change later. Fortunately, a lot of this information is readily available, or can be discovered during the first phase, which is information gathering.

The key difference between an SLO and an SLA is the concept of the contract. An SLO is an objective the Service Provider will TRY to achieve, but there are no penalties for NOT doing so. In the case of an SLA, there are negative consequences for not achieving the agreed-upon objective.

Once all of the components of the Business-Critical Service are identified and catalogued, the next step should involve classifying the types of logging available. Typically, IT Infrastructure folks will monitor the servers and the applications under their care. They will select "best of breed" solutions which can collect LOTS of different metrics. These generally fall into two categories: Alerts and Data-Points.

Alerts are used to let the Operational Teams know if something is going wrong. These will get triggered if a specific server application ends abnormally, or if a threshold (such as CPU Cycles used) is exceeded. These situations can have disastrous effects on the Business-Critical Application, so the Operations Team needs to act swiftly to remediate them.

Data-Points are pieces of information, collected over time. During the collection, there is no requirement for intervention or action on the part of the Operations Staff. This information collects data ove time, allowing for trending analysis. These can be used or exercises such as capacity planning or show back/chargeback models.

Form a purely technology viewpoint, the tools available today can monitor pretty much anything you can imagine. It is tempting for Management and Executive types to suggest that they want to monitor and alert on everything. The more information, the better, right ? Wrong ! Remember that all of the information that is collected needs to be stored somewhere. The more points of monitoring, the larger the data-store, the more information that needs to be correlated. This effectively slows the system down, unnecessarily.

During the interview phase, it is critically important to capture the Stakeholder's objectives. These could be:

1. I want to shorten the time to resolve trouble tickets
2. I want to understand how much it costs for a Business Unit to use the Service
3. I want to increase the visibility of IT Operations to the Business
4. I want to be able to demonstrate the availability of the Service

Collecting information that doesn't satisfy one or more of these objectives is of little or no value. So in order to keep the data-store manageable, the points of monitoring & alerting should be kept to the confines of these objectives. If the objectives change later, you can always add to the points of monitoring.

 

 

Chasing Shiny Objects

Shiny Objects

As my ITSM project continues, I am once again forced to have a series of uncomfortable conversations with my client. It seems that a smooth-talking sales rep has convinced an Operational Manager that they can solve all of their "monitoring and alerting" problems by simply ripping out what they currently have, and implementing a shiny new solution !

Shiny Services

Another Operational Manager has been consorting with a local Services Provider, who promises that if my client simply outsources their monitoring & alerting to them, all the problems will go away. For a low monthly fee ! Just sign a PO Mr Customer, and we can get started right away !

What's a Service ?

Now remember that the ITIL definition of a Service indicates that it is comprised as People, Process and Technology. In the first instance above, it appears that Manager believes he can buy a shiny new object, and all of his problems will go away ! That might speak to the Technology, but delivers nothing for the people or processes. In the second instance, the Manager is hoping to be able to outsource to the Services company, thereby dealing with the people aspect. But the Technology, and possibly the Processes are not being addressed. As such, neither solution deals with the underlying desire to take a "service-oriented" view of the IT Operation.

So in order to address this project properly, we will need to address all three facets of a service: Technology, Processes and People. I have re-ordered them because that is the most logical to me. I see the steps as:

1. Interview the Executive Sponsors to determine what their objectives are. In essence, I like to ask "What business problem are we trying to solve ?"
2. Interview the Operations Managers to determine what they see as being success criteria for the project.
3. Interview the Operations Team Leads. They will provide deep knowledge of the environment, the tools, and the current processes.

Technology

These three sets on interviews will provide the information required for the first phase of the project : Information Gathering & Gap Analysis. The Gap Analysis artifact is the first real Deliverable of the project. Once complete the Gap Analysis will help define what Technology is suited for the overall monitoring needs.

Process

I am in the middle of developing a series of Process Diagrams. These are visual representations of the processes that Operations personnel must go through when a specific condition is detected and alerted upon. There are two diagrams per alert - current state, and desired state. Any gaps between the two are highlighted and root-cause analysis is applied. Typically, these types of exercises uncover communications errors, and/or inefficiencies in the processes.

People

Finally, the thorniest part of the project is examining the People on the various Operations teams. This gets sticky, because the objective is to examine whether or not the team members have the correct skills to perform the Future-State processes, with the tools highlighted in the Technology section. It is never intended as a criticism, but many teams feel threatened by this step.

Summary

So as you can see, an ITSM Project is a lot more than a discussion of how to monitor IT Infrastructure. It involves examining the People and Processes as well as the Technologies. Simply buying and implementing a shiny new technology won't adequately satisfy the objectives of delivering Service-oriented IT.

What's Next ?

In a future BLOG, I will examine the second phase of this project, which involves classifying the collected information into alerts and data-sets, with an eye to event correlation & reporting.