Like many other ITIL instructors, I spend a fair amount of my time teaching certification classes. That said, keep in mind that for ITIL implementations to work, it requires the right combination of people, process, and technology. Can your teams effectively leverage your tools and processes to support a workflow that delivers sustained, aligned services? Most of the skills gaps I see are around bridging process silos…making sure inputs, outputs, and triggers are understood, managed, and automated where possible to facilitate incident and problem identification and diagnosis, coordinate transition activities, or align customer service requirements to achievable performance targets.
Category: ITIL
ITIL implies choices
A mistake many people make trying to use ITIL guidance is expecting it to be explicitly prescriptive (in other words, a step by step procedural how-to). That’s not what it’s intended to do. ITIL at its most useful describes a way of thinking about the work we do (from the point of view of our customers and how, or whether, our services are delivering the optimal value). At each level of detail, legitimate people will raise questions. For example, given the notion of Service Portfolio Management, the strategic decision to build an organizational capability prefaces the arrival of actual customers with explicit Service Level Requirements. Seldom is the real world quite so neat. For that matter, processes we associate with managing transition activities are often supporting strategic planning and prioritization of effort, processes we associate with operation are often providing explicit design and architecture support, and so on. In short, even ideas like the Service Lifecycle are nice models, but that’s what they are – models, and not even simple linear ones.
So what?
Service Management guidance provides a good jumping off point for thinking about implementing processes, services, and considering underpinning tools. In particular, it allows us to begin to define the key activities (and then it’s on us to describe more explicit procedures and work instructions), roles and responsibilities (which then need to be mapped to actual people and governance), and metrics (which then need to be turned into actual measurements with actual feedback, reporting, and oversight). Most of the time the academic arguments that find their way into discussion boards (is a reboot a change?) can be answered for a particular organization based on usefulness (Are we tracking reboot events? Are we logging incidents for which the reboot is a workaround? Are we tracking reboots as part of a change/release implementation? Are we tracking reboots for standard MTBF maintenance activities?)
The answer of course is clear – it depends on organizational need. Remember, the tools (and processes, and guidance) are supposed to work for you, not the other way around!
ITIL implementation — 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,
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 perceived to be losing? How do we maximize the benefits and minimize the risks of the change (sound familiar?)
Does cloud computing spell death to ITIL?
I recently overheard someone suggest that cloud computing could be “the death of ITIL.” This underscores a claim I’ve made for some time…that most people STILL think of ITIL as “an operations thing.” Certainly, cloud providers will continue to need to use mature, well-underpinned processes to manage the applications, storage, infrastructure, and facilities that the cloud service providers will deliver. Yet this creates a great new opportunity for enterprise IT; stop spending all your energy on reactive firefighting and start maturing your focus to look more in-depth at service strategy, cost/value, business alignment, and effective service brokerage that will deliver higher overall customer value.
In short, cloud computing may force us to do what we should be doing anyway…look at service lifecycles and outcomes and not just at processes and tools.
Common sense isn’t so common
Sounds like we’re having a few of the usual pseudo-debates on a number of the LinkedIn groups again…I always hesitate to get involved in these conversations because so much of this is common sense, but then again, perhaps common sense isn’t so common.
Certification v Experience
Isn’t this silly? It was silly for CNAs, MCSE’s, CISSPs, and every other certification too (would you like a lawyer who has passed the bar but never tried a case before? A doctor with no experience treating your illness?). Certifications are independent acknowledgements of certain knowledge…and perhaps some developed skills. Coupled with expertise, a bit of wisdom, and the ability to work well in teams, you may have the makings of a good teammate or team leader. People or employers who expect certifications to be a magic bullet are likely to get what they deserve…
Is ITIL a panacea?
People have religious-level discussions over whether “the book” (should we add holy?) says we ought to do a particular thing or follow a particular procedure. All manner of consultants, technical wannabes, and other pretenders pose as oracles interpreting the “word”. The ITIL describes a set of good practices that are demonstrated to work well in a variety of environments. Please understand that in no way does this mean that there are no other ways to do the same things well…or that all the “answers” will be found.
“The ITIL requires that we…”
ITIL is a set of books on my (and hopefully your) shelf, sometimes gathering dust, sometimes being very useful. The ITIL doesn’t require anything…but our management should require that we use well-tested, validated policies and procedures for how we design, provision, and deliver services.
Be pragmatic, everyone. The goal is simple…help our organizations and customers achieve their mission by providing effective, efficient, and well integrated IT services to support the business.
Integrating 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.
ITIL hands make light work…
Today’s post really is meant to remind all of us (myself very much included) why ITIL and IT service management matter. 20 years ago, if my email service went down, hardly anyone even noticed (On my BITNET account, I probably could send e-mail to about 5 people). Now, an e-mail outage can disrupt world commerce (ask anyone who has a Blackberry). Over the last 20 years or so, IT has transformed from a nice-to-have business enhancement to truly a utility – something that is basic and mandatory to operate virtually any aspect of a business.
This means that IT/business integration and alignment aren’t hackneyed buzz phrases, but absolutely necessary to the organization’s survival. We shouldn’t use the ITIL framework or any other frameworks, models, or quality systems to add certificates to the wall, but to enable our businesses to meet their mission. If our IT teams understand services and service culture at its most basic level as our role in enabling the business to achieve its goals, we will be much more effective, and a much more powerful asset for our business partners.
Changing the way we think about change management
One of the more challenging problems with deploying ITIL processes is our desire to make workflows linear. We teach the lifecycle one domain at a time, and teach processes in association with the book in which they are described. Reality is seldom so tidy, however. Processes like Change Management, Service Asset and Configuration Management, and Knowledge Management have a much broader scope; they span the entire service lifecycle and can become confusing if we try to limit them to a particular lifecycle domain. In this post, we’ll discuss the reasons why Change Management needs to be “liberated” from Transition, and how this simple idea will improve your organization’s ability to manage change.
Considering Change
Service Strategy describes the notion of managing a Service Portfolio. Our Resources and Capabilities define a set of Service Assets to be invested, with the goal of maximizing returns for our customer (Value Creation) and for the Service Provider (Value Capture). While many of these resources are invested in ongoing Operations activities (somewhere between 60-70%, depending on whose data you see), much of the remainder is invested in new or changed services in our Service Pipeline. The job of Service Portfolio Management is to define the Portfolio, analyze Business Cases for new or changed services, approve a new future state (in other words, choose the business cases we’re going to commit to doing), and charter the new portfolio (which has the effect of establishing projects to proceed to design and build the new or changed service in the business case).
While some Business Cases are requests for entirely new services, most come from different RFCs. Alignment between the Change Management process and what happens in Service Strategy and Design simplifies this workflow a lot. If we consider Change Management to begin in Strategy, RFCs begin with goals and objectives (e.g. removing a Known Error, implementing a CSI recommendation, etc.). By categorizing the Change, Standard Changes are weeded out and pre-approved, Emergency Changes are quickly driven to an ECAB for assessment, decision, and action, and Normal Changes are assessed by the appropriate CAB for cost, risk, impact, and business value. Given the scope of the Change request, some change requests can be handled at lower levels of the organization (though still through formal change management) where larger scope and resource-impacting changes should have Business Cases developed and these considered together as part of the overall Service Portfolio Management process. As a result, we have consistency in our Change Decision Authority, resource alignment and allocation across projects, and a consistent means of prioritizing the work to be done.
Once an RFC is approved, Service Design describes how we build the change, with the Change Management process continuing to coordinate multiple changes and working with other processes to prepare for effective Transition. This could include planning testing and validation windows, scheduling access to build and test environments, planning how changes will be packaged for release and deployment, and verifying business fit. “Coordinating Change” then largely is described by monitoring status of change build, ensuring proper Service Transition and Operational Readiness Plans are in place, and ensuring that communications is maintained among the various technical, process, and business stakeholders. Once the Service Design Package is complete, Release and Deployment Management can take the change and its associated documentation into the DML and coordinate appropriate packaging, build, test, and deployment/installation of the change according to our transition plan. Once deployed, Change Management finishes its workflow as always with a Post Implementation Review confirming technical success and business outcome (based on the Evaluation Report’s assessment of Change Acceptance, Predicted, vs. Actual Performance, and “unexpected side effects”). Assuming we’re good to go (with other remediation as necessary), we can close the Change at this point.
By thinking of Change this way, it’s easier to see how to use groups like PMOs to help adjudicate how projects align to new and changed services, portfolio management goals, and how to align Change authorities more sensibly. Most importantly, it improves our likelihood of delivering well designed, planned, and effective changes more quickly, improving our ability to adapt IT services to meet our customers’ changing needs.
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 many 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.
First of a new series of 5-minute ITIL tutorial videos released
I’m pleased to announce that we have started to publish our new ITIL Results in 5 Minutes daily learning snippets. Watch the first installment, Why Availability Shouldn’t Wait.
Please feel free to request topics via the comment button!