Conditions of satisfaction: the key to ITIL-based activities, deliverables and roles

Most efforts aimed at clarifying activities, deliverables and roles based on ITIL are fairly good at getting the activities assigned, the contents for the deliverables documented, and roles assigned to individuals.  What they are typically not good at is making sure "what good looks like" is defined for each of these three.  As a result, the organization is missing the key ingredient to making all of this a success: the "why".  While this is understandable, as there is a lot of work necessary to get the "what" to do in place, without the "why"--the end in mind you're shooting for, chances of arriving at where you want to be in terms of improvement are slim in my experience.  This is one of the top insights I can provide you when it comes to ITIL implementation, or any organizational change effort for that matter: focus on outcomes over activities.  This doesn't mean you don't have to identify and assign activities--you do--but an understanding of the outcomes we're shooting for trumps assignment of activities every time.  Said another way, if I had a choice between working in an organization that "got it" and "got on with it", versus one that didn't "get it"--the outcomes that we are shooting for, how we should measure each other, and how ultimately customers and users will measure us--or "get on with it"--act on that knowledge every day in large and small ways--I will opt for the former every time.  It is awesome when people know the why.  Here's what it looks like: 1) for each activity, make sure two columns of data are defined, first, the activity, and then a standard that answers the question, "performance is effective when..."; so for example, if the activity is answering the phone on the Service Desk, the standard might be "All calls are answered within 3 rings". 2) same goes for deliverables--it's not enough to have a functional specification of the feature set--you must define acceptance criteria for each; so column one lists the bill of materials of the deliverable; column two lists acceptance criteria.  So for example, if the deliverable is a final report, one element might be the executive summary, and the acceptance criteria is that is is no longer than one page and summarizes the vision, the problem, the solution, and the benefits of the solution. 3) same goes for roles--these are clusters of activities usually grouped into like parts; each activity must have an associated standard of performance. All of these things are about making sure that not only is the thing itself specified--the 'what'--the activity, deliverable, or role--but the "what it looks like when it's done right"--the 'why' or acceptable outcome is specified to the right level of granularity.  This is what we mean by conditions of satisfaction. I encourage you to incorporate this in your ITIL efforts.  It is very interesting to watch groups put these together, to see what individuals on the same team think the relevant activities, deliverables and roles are, and what it looks like when it is done right. Besides the output of defined activities, deliverables and roles along with associated standards of performance, such sessions also result in one of the most important thing you can have to drive success in your ITIL efforts: alignment as a group on "how we do things around here" and "what good and right and done look like".