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!

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