ITIL Implementation and the Big Picture

I'm currently helping to support a large scale introduction of the ITIL processes (at least some of them) to a large military organization. While there is a lot of focus on the blocking and tacking around processes, supporting tools, and the like, it never seems to amaze me how every one of these adoptions are really exercises in managing organizational change. Perhaps the most important role on your ITSM team is the role of the Communications Manager, because they have to really drive both the client organization and the project team through Kotter's 8 steps to Organizational Change (for a quick read on what these are, see http://www.mindtools.com/pages/article/newPPM_82.htm

The fundamental reality of life is that people resist change for survival reasons. I know how to survive today. If you change something, I might not know how to survive tomorrow. So I resist. If change is forced upon me, I will adapt, lessening the pain (by not complying) where possible.

In an organizational context, this is a recipe for disaster. If you wish to be successful in your project, you must be successful in creating buy-in and real commitment from the customer. This is very simply a game of WIIFM (What's In It for Me?). For every stakeholder, you MUST understand the WIIFM, and communicate (again, and again, and again) and get buy-in to that to gain the trust and commitment of that stakeholder. Many times, this isn't a process issue, or a tool issue, but a political one. What are they winning? What are they preceived to be losing? How do we maximize the benefits and minimize the risks of the change (sound familiar?)

What you need to know about ITIL...

Was just reading a white paper that a co-worker of mine was using to help explain the basic objectives of ITIL, and it was reflective of its publishing time, mid-2007, when many of us were struggling to figure out exactly how the alignment of V2 processes and the V3 lifecycle would work. There are mnay good summaries (the ITIL Pocket Guide is great...if you already know it anyway), but you might use this approach to explain it.

While many people think ITIL is about processes, that is at best an incomplete point of view. ITIL is about changing people's perspectives about the tasks at hand we perform in IT. It's not about the technologies, or even the whole end-to-end IT services, but how (or whether) these services effectively underpin our customer's business processes and enable the business's outcomes; revenue, profit, market share, or simply meeting the organization's mission and vision.

IT Service Management then is about how we produce, maintain, and sustain services to deliver VALUE to our customers (in the form of services that enable them to perform better, faster, or more cost effectively than they might otherwise). The Service Lifecycle that underpins ITIL describes 5 key aspects or stages of this effort. While there are much more authoritative conversations about the following, if you get the following big ideas, you're on your way to really understanding ITIL.

1) Service Strategy - In life, we don't get everything we'd like. This is usually because of constraints; time, money, a jealous spouse, you get the idea. The goal, therefore, is to maximize the value we can create (and that we get!) given the limitations we have. IT Service Strategy works the same way. There may be many things we would like to do, but given our time, money, and other resources at our disposal, which ones will we commit to do, and how do we decide? The concepts of Service Portfolio Management, underpinned by Financial and Demand Management, populates good Business Cases for how we can choose wisely.

2) Service Design - Once we've decided that to provide a particular capability would be a good idea, we need to align our customer's requirements and desired outcomes with our service targets. This includes decisions about the service's utility (what it does) and its warranty (how well it does it, how well it's protected, how much of it there is, etc.). Service Design takes theoretical models of what a service MIGHT be and transforms it into actual working services, with transition, operational, management, and measurement supports.

3) Service Transition - Regardless of whether we're looking to add a new service, change an existing one, or retire (or transfer) one altogether, transitions create risk. In particular, risks of causing business impact and disruptions when we deploy changes. Transition is about managing those risks and delivering the intended value that drove the business objectives and goals in the first place, and ensuring that we effectively move services out of development and into production...without blowing stuff up.

4) Service Operation - Once services are live, customers have one basic wish...keep them up and running so they can work. Service Operation describes proactive and reactive ways to manage, maintain, and support live services to keep them available and keep the business processes flowing.

5) Continual Service Improvement - The magic word here is continual...not occasional (or never, except when the boss is really mad). All services and all processes can improve; we learn, and the magic trick is to be culturally agile enough to make many, many small iterative improvements to your services and processes as you learn them. This can be as easy as building a knowledge base of known incident resolutions and Known Errors, or can involve detailed trending analysis in the search for performance enhancements. If CSI becomes "normal" in your culture, you'll learn what many other types of organizations have learned over the last 60 years; that while managers the world over seek "quantum leaps" in improved IT performance, most of the time real organization maturity requires time and a consistent willingness to "hit singles", or make small improvements that consistently build up lots of small, incremental benefits.

I don't pretend that this is ALL you need to know about ITIL, but many people who hold ITIL certifications miss the bigger picture. Yes, there are processes, functions, roles, etc. They are a means to a bigger end; customer outcomes that help that customer meet its mission and compete and win in its market space.

Making sense of Cloud Computing - Part 1

One of our customers has asked us to produce a short course on Cloud Computing. While it's always easy to chalk this up to yet another round of IT Buzzword BINGO, the business models driving the interest in cloud computing are real, important, and must be understood if you want to be able to sustain your service value for your customers. This week, we're going to look at a number of different aspects of cloud computing and why they matter. We'll also take an honest look at the challenges that these models create, especially for security and privacy.

Today: Financial Models and Utility Computing

Most IT managers and staff are used to working with tangible service assets they own; hardware, software, tools, and other assorted infrastructure, applications, and platforms. Based on our available resources and organizational capabilities (knowledge, skills, processes, etc.), we would design, plan, develop (or buy), and deploy services in support of our clients. This required the IT organization to use the business's capital to invest in IT assets, which may or may not be optimally utilized (consider hardware utilization, applications and associated licenses, data center infratructure and environmentals, etc.). Capital investments require a substantial commitment of time and upfront money to create a capability, long before a payback period begins (when the new service is delivering value in operations). If the business's needs evolve, substantial changes in service warranty are needed (capacity, service continuity, security, and availability) and will require rearchitecture, re-provisioning, and ultimately waste time and resources.

Most businesses seek a different model (and not just for IT!). Businesses generally prefer operating costs (pay-as-you-go) to capital costs, because we can stop buying it if we don't need it, or request more capacity or a different level of continuity or security (availability is a bit messier, as we'll discuss later this week) for an understood price per service. Utility Computing is really nothing more than delivering on the promise of ITIL Service Level Management, where for an understood and agreed price we will deliver an agreed level of service at a defined level of quality. The biggest difference then is WHERE we will deliver it...

In the Cloud Computing context, as with the ITIL Service Model, we seek to deliver value to customers while avoiding the ownership of certain costs and risks. Depending on the level of Cloud Computing your organization may consider, this includes potentially choosing not to own

- Applications - we'll use providers with SaaS (software-as-a-service) models to host and deliver key software applications, especially generic ones like productivity applications (a la Google docs) and ones where access across a number of devices and locations is a strong benefit (CRM applications like salesforce.com)

- (Development) Platforms - we'll count on our cloud providers to provide our developers with rich toolsets for building and deploying cloud applications; for example, Microsoft Azure extends .NET developers tools to build in the cloud.

- Infrastructure - we'll take advantage of the benefits of server virtualization, grid computing use of processing capabiliites, and enormous server farms managed by providers such as Amazon, Google, IBM, and many others to scale our storage, data management, and processing needs as they evolve, and make agility and real Capacity management far more accessible and realistic.

As our ITIL readers know, effective provisioning of whole services to customers involve the correct combination of these three things aligned with the business's needs and managed to deliver a reliable underpinning of their key business processes. Clearly cloud computing has enormous implications for the entire service lifecycle. To deliver "utility" computing, we must do more than just create pay-as-you-go models; we must actually deliver the right level of utility!

Next time, we'll talk about Cloud Architecture

Linking ITIL with Project Management

One of the many issues facing organizations trying to get substantial traction with ITIL initiatives is the incorrect perception that ITIL is "for operations." I can't begin to count the number of developers and project managers who have openly asked in one of my Foundations classes "this isn't for projects, right?" Well, yes, of course it's for projects, since projects are how we perform most activities in IT; design, development, service improvement projects, new service initiatives, and the list goes on.

In many cases, the ITIL community is firmly responsible for this misconception. Asked to describe their ITIL adoption and good practices, they inevitably point to Service Desks, Incident and Problem Management processes, and occasionally Change Management or a CMS tool implementation (often without an underlying CM process to drive its use or efficacy).

With ITIL v3, we have a chance to fundamentally reset everyone's expectations of ITIL. We now acknowledge the whole Service Lifecycle, beginning with Strategy. It's reasonably easy to see the parallels of the activities of Service Strategy and Service Portfolio Management with a PMO; look at business cases, assess ROI and VOI, and approve and charter projects. Likewise, Service Design and Transition provide clear processes and guidance for managing the tactical aspects of capturing functional, nonfunctional, and usability requirements (think utility and warranty), performing service and measurement design, developing or acquiring applications, infrastructure, and metrics management tools, coordinating testing and validation, and overseeing transition planning and execution and operations uptake. These are the fundamental parts of planning and executing any good IT project, and would look very familiar to a PMP. By the way, these models work brilliantly in agile development models as well as more traditional waterfall approaches (which don't work, but that's a different post).

The biggest risk we have for successful ITIL adoption is that very often senior IT management really has no idea what ITIL really is. They think in terms of the most basic Service Operation processes, the Service Desk function, or maybe Change Management, but generally have absolutely no idea how ITIL helps to bridge the yawning cultural chasm in many organizations between Development and Operations. When we teach that Management Commitment is a mandatory critical success factor for ITIL implementation, it begins with basic understanding and clarity of vision across the Service Lifecycle.