ITIL Archives - Deep Creek Center

ITIL Practitioner: Finally the ITIL Certification we actually wanted!

With the upcoming February launch of the new ITIL Practitioner certification, we finally have the answer to the most frequently asked questions about ITIL.

What do I do to get started?
What should I focus on first?
What is the “next class” after Foundations?

ITIL Foundations has enormous scope; from strategic planning to continual improvement, from service architectures to operational support, from knowledge management to portfolios. As a 3-day class (and usually as two and a half), it is designed to provide persons new to service management with an extraordinary amount of information in a short time, much of which is new and outside the immediate scope of the work that person performs on a daily basis. In many ways it begins a journey of awareness of how IT organizations as service providers create value for customers, and how each of the stages of the service lifecycle drives and improves the value to the business.

But then the proverbial question…what do we DO now that we know all this?

ITIL Practitioner is fundamentally different than all of the other ITIL credentials. It is intended specifically to address “how-to” ; what exactly should we DO to start the ITIL journey successfully in our work, our teams, and our organizations? It is grounded in 9 key principles broadly shared with agile and other continual improvement models, and backed with specific tools and techniques to get started. It focuses on helping to instill continual improvement and leverages industry best practices in organizational change. It reinforces the need for strong metrics and measures to meaningfully assess, for better or for worse, “where are we now” so we can work to build meaningful and demonstrable improvements.

The 9 principles are broadly outlined here

Start where you are – Virtually none of us are working in greenfield environments, or with no existing processes or tools. Start your journey practically by looking at existing practices and working to improve them, as opposed to rip and replace.
Focus on Value – Many organizations become consumed by implementing new policies, processes, and especially ITSM software tools. The focus instead must be on the value to the customer; how do these things help us improve efficiency and effectiveness, reduce costs, and improve results?
Work Holistically – Service at its most basic means thinking end-to-end. How do all of the hardware, software, people, and other resources and capabilities make and support outcomes customers want? For many organizations one of the first steps in the ITIL journey must be to start “thinking in service,” instead of in technology components. This raises issues about coordination across technical/functional teams.
Keep it Simple – There are lots of potential places to begin service management improvements, and many improvements to choose from. Eventually success is driven by keeping your approach simple and straightforward, and focus on how specific, simple improvements to processes, tools, and teams can enable meaningful value for your customer.
Be Transparent – There are lots of “political layer” issues that can derail improvement initiatives in any organization…what’s the “real” reason for the change? Transparency demonstrates to the organization that we are committed to delivering the best that we can, and also demonstrates to stakeholders the very real constraints that we face. Rather than overpromising and underdelivering, transparent practices enable clarity of understanding across stakeholders and facilitate prioritization of efforts to improve value.
Collaborate – Most service provider organizations consist of a number of very smart, talented, and diverse individuals, with different levels of background and experience that can be brought to bear to improve services and processes. Creating effective collaboration models enables better solutions, improves buy-in, and demonstrates that this is a “team game.”
Progress iteratively – All of your processes and practices got to their current state through small, iterative changes over time. While many managers seek “zero-to-hero” improvements, iterative and consumable improvements are demonstrably better at creating lasting change, as anyone who has been able to lose weight AND keep it off will attest.
Observe directly – People often tend to look exclusively at reports and make important strategic decisions without direct engagement with many of the key stakeholders. Whether we’re trying to improve a business process, or facilitate operational improvements at a service desk, direct observation of the work will help us to better understand the processes in question (and find gaps in the process documentation!) This will help us to prescribe satisfying solutions that deliver the intended benefits, with the direct inputs of the key stakeholders improving buy-in and commitment.
Design for Experience – Many services “work” in the sense that they tick a list of requirements boxes, but don’t take into account the unique needs of the users of the system to successfully execute business process workflows. Service designs must take into account not only what a system must do, but what people must do, and how real people use the system to deliver value. This means a much greater focus on use and use models, and development approaches like Scrum or XP that focus on whole slices of solution based on a business and user need, not just a feature list.

One of the key benefits of the new guidance is specific tools and templates your team can adopt and adapt for immediate use to get started. These include templates for business case development, CSI tools, CSF and KPI development, assessment tools, communications tools, stakeholder management, and much more. Training programs for ITIL Practitioner focus on teaching your teams how to use these tools for immediate value.

I do like to think of the ITIL Practitioner credential as the ITIL certification many of us have been seeking for a long time, especially in the enterprise. I recommend this program for ALL ITIL candidates. While it is suitable for students fresh out of Foundations, the scope of the credential is so different and the approach so practical and useful that I strongly recommend it for all of my ITIL-credentialed students, up to and including ITIL Expert and even Master. I’m genuinely excited about what this will do for all of our customers trying to “get past talking” about ITSM and get demonstrable results. Good luck and reach out to us if you have any questions at all about this or any other ITIL issue.

Portfolio of What?

Many organizations struggle to understand and differentiate project portfolio management from service portfolio management. This is an important distinction, because project portfolio managers understandably focus on the project portfolio. This is useful, but ultimately misses the point of looking at the investment of service assets across the service lifecycle.

The basic idea behind service portfolio management is simple but profound. We only have a finite number of service assets available to us, and the goal is simple in concept though tremendously difficult in practice: optimize the value you create for your customers, and the value you capture as a service provider.

Strategy is fundamentally about dealing with constraints. If we didn’t have constraints, we wouldn’t really need a strategy, just a plan to execute. Because we are not omniscient, we need to establish strategies to help us best assess cost, risk, and value of delivering different types of services.

One of the fundamental objectives of most service management initiatives is optimizing investment, especially in areas of the organization such as service operation. By using service portfolio management, the focus is not only on optimizing the performance of projects, but ultimately the shifting of resources from reactive activities to proactive activities that drive better value for the organization.

Many organizations focus on the service operation and transition process areas of ITIL, but much of the better value proposition is actually higher up in the service lifecycle. Take the time to explore some of the value of the service strategy and service design books.

Build out the higher end processes. It’s well worth your time and investment.

Free ITIL Lessons Learned Webinar Coming Soon

Lessons Learned from 200 ITIL Implementations over 20 Years

Don’t miss our upcoming free ITIL webinar on “Lessons Learned: Best Practices in Implementing ITIL Best Practices.” Deep Creek Founder and President Patrick von Schlag will review many of the most critical issues organizations face in implementing ITIL and how to overcome them.

Filling the ITIL void

As many of you know, I’ve been intimately involved with ITIL practice for more than 10 years. I am launching this Lessons Learned, user-consortium-driven blog to document good practices based on the ITIL and other frameworks.

My hope is that this will be a great place to get facts and support for making ITIL work in your organization. Your moderator does not claim omniscience, and so I hope that each of you will share your own wisdom as well.

This is a great place to ask questions, share success stories and get the support and tools you need to make ITIL work in your organization.

PM and ITIL

I have been thinking about Carol’s and IT Skeptic’s comments about PM (and have read the thread he pointed me to, and an awful lot more) and I still think this comes down to a simpler notion. We have a yawning, enormous gap in most IT organizations between Design and Operations, in many cases cast in stone through outsourcing deals to different entities with no aligned targets or shared accountability. This creates the hot potato issue with which so many of us are familiar, and which really drives my interest in service transition, and particularly in placing Early Life Support (ELS) firmly in the hands of Release and Deployment Management. It is in fact the job of PM to manage the SUCCESSFUL transition of their project deliverables (which we’ll assume to be a new or changed service) into the live environment, and to support it until

1) The service is accepted by the customer AND
2) The service is meeting its designated service levels (this implies successful event mgmt, operational monitoring and reporting, and other operational readiness capabilities that really should be flushed out more as part of testing and validation activities).

Project Management (and Software Development Lifecycle Mgmt, but that’s another article) need to be able to coordinate service design and transition activities, and I would liken it to the approach ITIL takes with functions. PM necessarily coordinates across all the activities in service design and transition…based on the scope of their project. Process team leads perform activities across multiple projects in support of process goals and objectives (which should map to project goals around, for example, functional and non-functional (or warranty!) requirements).

The actual ITIL books don’t in fact describe exactly how to run projects (and rightfully leave this for the complementary guidance), but like a similar discussion currently on one of the LinkedIn threads about how ITIL leaves appropriate space for governance models (can anyone say CObIT), it really does so for PM as well, leaving flexibility needed to encompass large programs and small projects alike, while still providing a core set of building blocks needed to build a good service.

I’d like to hear from all of you…where do you see the big gaps, and what are your recommendations for addressing them? If you were writing ITIL 4.0, what would you add/remove/change to improve the efficacy of the guidance?

Engagement

If you look at the descriptions of Critical Success Factors associated with ITSM adoptions, the first one on almost any list is Management Commitment.

Sounds good…until you try to figure out exactly what that means…

Management Commitment is more than just the willingness to train people, or buy software, or even have big Communications strategies about how important ITIL is…it’s the willingness to BE committed. The best way to actually measure this is willingness to sign up for roles like process and service owners. In order to ask for accountability from IT teams and to employ meaningful governance and oversight of Service Management, the senior managers (with enough authority to enforce commitments) must be willing to commit themselves as well. IT staff notice when senior teams make real commitments, and will align their efforts accordingly.

I recently watched a short promotional video from one of the major ITSM vendors (I’ll protect the guilty, but you can find it quickly if you look). It depicts a CIO describing the value of Business Service Management, and includes a roundtable with his senior IT staff. Ironically, the copy from the video is more typical than ever.

“I think we should tell the IT staff about the commitments I made on their behalf, so they know what I need them to do.”

Can’t get buy-in that way!

If you want IT organizations to commit to Service Management, IT leadership has to commit itself to processes like Service Level Management, which prevent “free lunch” behaviors and encourage the business to work cooperatively with its customers to evaluate evolving requirements against achievable targets. This involves listening to both clients and IT teams, and working to establish collaboration that focuses on the business value of the outcome, not only “do more with less.”

CIOs need to focus on business outcomes, and then work closely with their teams to support the optimal level of service to meet those needs, balancing cost/value. Taking specific service ownership of a key business service (perhaps, say, an online marketplace critical to sales growth) and taking specific accountability for service outcomes related to that service will raise the game a great deal, and drive the interest in metrics, continual service improvement, and ultimately business results. Once a CIO signs up for the most mission-critical one him- or herself, it’s a lot easier to get other senior managers to sign up for other services, and really establish cross-functional “service views” of the world.

Management Commitment is good talk, but, most of the time, talk is cheap. If you want to see results, demand real commitment, and real action. It will help you dramatically improve your results!

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?)

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.

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.