The Need for Speed

Trends such as virtualization, cloud computing, and agile development have all prompted the need for leaner, more efficient, and more highly automated ITSM processes. Probably one of the things that is most misunderstood about ITIL is that it is a highly scalable framework. Organizations need to understand that if their processes are bureaucratic, it’s most likely because they have made them that way. So in the spirit of continual improvement, what’s an organization to do… throw out ITIL and start over?

That’s what the DevOps folks would have you think. If you haven’t heard of DevOps, according to Wikipedia the term refers to the emerging understanding of the interdependence of development and operations in meeting a business' goal to produce timely software products and services. DevOps has been referred to as (1) a movement, (2) an approach, and one blogger went so far so refer to it as (3) a “framework of ideas and principles designed to foster cooperation, learning and coordination between development and operational groups.” Launched by a group of European system administrators, the spirit of DevOps is relatively sound… let’s all understand that in this day and age, technology (and more specifically, software) is and must change – and change FAST – or the business isn’t going to make any money. To move quickly, and yet not so quickly that we wreak havoc of the production environment, the “dev” and “ops” folks have to work together.

Proponents of the DevOps movement talk about things like culture change, unified processes, and unified tools… all concepts that are central to ITIL. So where is the disconnect?

We all know that ITIL understands the interdependence between development and operations and the need to foster cooperation, learning, and coordination. We also know that, at times, it can seem that ITIL does so in a heavy-handed way. Controls imposed by governance and security and sometimes just by management’s need to be in control can all add up to less than efficient processes.

So what’s an organization to do? It’s called continual process improvement. It’s remembering that processes are never “done” and there is always room for improvement. It’s remembering that process maturity and culture change takes time and doesn’t end when the processes have been documented and are being supported with a tool.

Continual process improvement involves continually looking for ways to streamline and integrate processes and automate the associated activities. Here are a few good places to start…

Models - Earlier this month, more than 240 people attended Jayne Groll’s webinar Using Models for Incident, Change, Problem and Request Fulfillment Management. The Q&A session associated with this webinar went on for an hour. Models are a basic concept that may be missed during the initial design of a process. Even organizations with advanced ITIL knowledge may fail to fully utilize this valuable concept.  Models = efficiency, models can easily lead to automation, and models are a much needed helping hand at a time when we’re all being asked to do more with less.

Standard changes - Folks often understand the concept of standard changes but apply that concept only to basic things such as installing desktops and commercial software. Virtualization and agile development are prime candidates for the use of standard changes, as are many of the other activities that IT organizations perform on a daily basis. A good place to start is by initiating a project aimed at increasing the number of standard changes. This could involve first further defining what a standard change is and then a set of specific procedures (models) for putting those changes in production. One client shared that they set up a temporary CAB whose role is was to evaluate and implement standard changes. Once the criteria had been fine-tuned and the most frequently performed standard changes had been formalized, the temporary CAB was disbanded. This enabled them to quickly increase the number of standard changes without impacting the work of the main CAB.

Release and deployment management – This process handles much of the coordination between development and operations and is increasingly becoming a hot topic for organizations. A recent ITPI study concluded, “Change management is often identified as a logical starting point for ITIL implementations. However, release management should be the destination for those organizations wanting to achieve performance gain from standardizing on ITIL change and release practices.” An important aspect of the release management process is the release policy. It is often the release policy that dictates how quickly changes can be made and when. In Service Transition, the release policy is an important component of overall transition planning and support. Today, company’s release policy and release management process and procedures must be scalable and flexible. Are there some changes that require tremendous rigor? Sure. Are there many other changes that can be planned, tested, and deployed more quickly (by using models, templates, and automation)? Absolutely.

ITIL can seem overwhelming, particularly at the Foundation level. It can at times seem impractical to those “dev” and “ops” folks who are struggling to get by. There are tremendous opportunities, however, to demonstrate how scalable and flexible ITIL can be and to show how it can be used to do what we all need to do in this day and age… speed up!

Strategic Thinking

What is strategic thinking? This question often crosses my mind and those of my students, especially when I am teaching the ITIL Lifecycle classes. Just as often as the question arises, a variety of answers are put forth as well.

One definition of strategic thinking holds that “the role of strategic thinking is ‘to seek innovation and imagine new and very different futures that may lead the company to redefine its core strategies and even its industry’ ". This implies that the definition and use of strategic thinking are related but different from strategic planning—putting into action or executing the ideas developed using strategic thinking. Strategic thinking is just that—postulating or thinking about what the future holds and what the future looks like. Strategic planning is action based. A good organization recognizes they need both.

As a Professor who attempts to provide learners with theory-driven practical data, information, knowledge and wisdom, I particularly like the difference in definition between strategic thinking and strategic planning. But how do you learn to use the two approaches differently yet in a related manner? I think one key is in the deliverables.

The key deliverables of strategic thinking should be a vision, a mission statement and a values statement. In this context a vision is a mental picture of what you would like the future to be for yourself, your company and your industry. A mission is a basic statement on how you would like to go about achieving that picture of the future. The mission then becomes a key input to strategic planning, which develops action steps from the mission. The values statement identifies the core beliefs and convictions you will stand by as you move forward towards your vision.

The key deliverables of strategic planning are your objectives, goals, strategies, plans, and critical success factors that serve as a roadmap and toolkit for achieving your vision. Since the vision is a picture of a broad horizon, strategic planning helps you lay out the details, milestones, vehicles, elements and conditions required to achieve success.

Once you have used strategic thinking and strategic planning to layout your future, you will have completed top-down design of what success looks like for your customers and your organization. You will need to follow up the top-down design by building your capabilities from the bottom up as a validation of design. You will need to identify the processes, roles, key performance indicators, measures, metrics and tool sets that will enable you to reach your vision.

Remember that you need to do the top-down design before you do the bottom-up build. Otherwise you risk putting the proverbial cart before the horse. Taking too operational a perspective on how to serve your customers can take you away from the benefits of strategic thinking and planning and place you into a “just do it” mentality that can often lead you in directions you did not intend.

You will continue to go in this strategic thinking/planning and capabilities cycle using Continual Improvement as a guide towards quality. Each cycle will help you refine your vision and improve your roadmap and toolkit until you are moving along the journey to success as a well-oiled machine.

So do not hesitate: start thinking and planning strategically today!

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors).

A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2)

1. People:  Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs.
2. Products:  These are the technology management systems utilized in the process of IT service delivery. When designing a new or changed service consideration must be given to the capabilities of how these tools will enhance the delivery and support of the customer agreed services.
3. Processes:  Used to manage and support the services to meet customer expectations and agreed services levels. Design must have the requirements on what the business and IT have agreed to as success. A characteristic of all processes is they must be measureable. Processes must have Key Performance Indicators and Critical Success Factors that align to both the short and long term goals and objectives that the business has communicated.
4. Partners:  Are our primarily vendors, 3rd party software companies, manufacturers and suppliers involved in the provision of IT services. The process must be designed so they are managed to support IT targets and business expectations. Awareness of the business context and how this relationship works to realize business benefit shall be considered in our overall design.

Without these critical success factors being part of our Service Design Package (SDP) a service provider cannot possibly have a successful design or project implementation.

Application Cost Models

The Professor was recently asked about Application Cost models. 

While ITIL does not speak specifically about “Application Cost Models,” there is information about how to create a service cost model using ITIL’s Financial Management process.  From ITIL’s perspective, an application is one part of an end-to-end service.

Developing a cost model involves:

1. Identifying all costs attributed to the service (hardware, software, salaries, accommodations, external services, transfer costs (e.g., from other internal units)
2. Determining which costs can be directly tied to the service
3. Deciding how to fairly apportion indirect costs (e.g., infrastructure, technical staff time)
4. Adjusting the total to allow for unabsorbed overhead costs (e.g., administrative or managerial salaries, building/accommodation costs such as a data center or IT office space)

A spread sheet can be used to break each cost down into a unit cost.  Overall cost for the application (or service) can then be calculated based on usage.

Problem Management Techniques

Perhaps one of the most underused yet powerful processes from ITIL is Problem Management. Many people recognize the importance of Problem Management, especially in relationship to Incident Management. Yet when I ask students if they have implemented a Problem Management process the response is often “We plan to...” or “We started but did not get too far…” or “Not yet.” So what is keeping companies and individuals from using Problem Management to its full effectiveness? I propose that some of the reason is fear, uncertainty and doubt about how to go about “doing” Problem Management.

By understanding that the Problem Management process has a number of techniques and tools available to help a service provider indentify root cause and recommend permanent resolution we may be able to remove some of the fear, uncertainty and doubt.

What are some of the techniques and how could we apply them? Let’s take a brief look and see what we can uncover.

• Chronological Analysis: This time based approach lets us look at the order of events to help identify a chain of cause and effect. It is particularly helpful when looking at potential problems that have developed slowly over a period, yet have distinct symptoms.
• Pain Value Analysis: This technique helps us narrow in on particular impacts that result from incidents and events that are troublesome for the business. It allows us to separate and prioritize items when we are facing a number of problems simultaneously.
• Brainstorming: This collaborative method allows a number of subject matter experts and knowledgeable individuals to come together to share prospective ideas about the cause of a problem. This permits us to have many eyes and minds seeing a problem from different perspectives, thus broadening our problem solving capabilities.
• Kepner-Tregoe Problem Solving Method: This well known method provides a formal approach and set of steps for identifying root cause, recommending a solution and implementing the solution. When formality and structure is needed—e.g. a major problem or large impact—this method would prove particularly useful.
• Ishikawa Diagram (Fishbone): This visual technique allows the service provider to frame a question and develop possible causes using a structured, categorized approach. The technique is one of the most powerful and really is hard to do in an incorrect manner. This might be a good starting point for some of the other techniques.
• Pareto Analysis: This prioritization helps the service provider focus in on the problems with the greatest impact. Based on the idea that 80% of incidents result from 20% of the problem causes, the method allows tackling problems in the order of greatest return. When coupled with the Ishikawa diagram it can be a very powerful tool. 

These Problem Management techniques provide us with a toolkit for identifying root cause and then determining an appropriate recommended permanent resolution. They seem difficult and complex to use but in reality they are each a straightforward method. The struggle may come when determining in which circumstance to apply which technique. Although I mentioned briefly some possible uses, these methods can be used in a variety of circumstances and with any number of problem types.

The success of Problem Management comes from taking the time to execute the process and use some or all of the techniques provided. Making time for Problem Management may detract from time spent resolving Incidents. The irony is that if you do not make the time for Problem Management you will only ever have time for Incident Management, which can consume large amounts of resources. Problem Management is not as resource hungry, but it requires special devotion and attention to see it succeed.