A few lines of code can change an entire banking system.  One bad patch issue can take down an entire mobile network.  We’ve seen it.

In other words, the term ‘viral’ has real meaning today.  It means not just a hyperbolic effect/adoption curve, but more precisely it refers hyperbolic effects stemming from apparently puny origins.

But ‘apparently’ is an important qualifier here.  I think the real fact is that the platform from which most changes originate–certainly technological ones–is so tall that many origins are only apparently puny.  We have real power.  Adult supervision is increasingly important.

More generally, I’ve thought for a long time that one of the most vexing truths of modern existence lies in the fact that our ability to change things generally far outstrips our own readiness for change.

Entire libraries of pop-business advice exist which offer tips on dealing with change. Cartoon characters (“Mordac the Preventer”) have been created to personify the situation.  It gets personal too:  hold onto your habits too dearly and you’re likely to be branded “change adverse” by faster moving peers.

Though a lot of what’s out there seems to focus on how we as individuals cope with change, the larger truth is what I began with above:  we’re better at changing things than we are at changing.  While the “just do it” or “just get used to it” approach to change has a place, it’s nowhere near a panacea.  Pretending that it is or that it can be leads to a lot of organizational dysfunctionality and underperformance.

When it comes to tackling large scale change in particular, organized transition management offers a much more powerful tool than individual attitude adjustments or pep talks.  Transition management is an admittedly imprecise term, but generally speaking it amounts to a structured, stakeholder-focused, managed effort to ensure that an organization is ready to make good use of the change it’s about to receive.

In another way of saying it, there’s the change itself and then there’s the socket for the change.  Transition management is mostly about developing the latter.

Though it should be obvious, the penalty organizations pay for simply assuming they’re ready for change is low return on investment if not outright damage from the change.

By themselves, changes only create confusion and cost money to implement. The bigger the change, the more potential for chaos and the greater the cost of implementation.  The only time changes result in benefit is when they reach production.  Translated, “reaching production” means that the organization has successfully integrated the change into its business practices.  That means the “socket” is working.

Most of the change projects I’m involved with have some technical component to them. In those projects, the overwhelming tendency is to assume that prepping the technology (the change itself) is enough to be successful.  It’s the oldest (and most predictable) mistake in the book.   Technologists far to easily assume it’s all about the technology.  It’s the “If you build it, they will come” approach in a way.

Certainly the huge ascendancy of ‘pull technologies’ (e.g. opt-in technologies) over older ‘push technologies’ (e.g. use it and get used to it technologies), superficially supports the illusion that ‘if you build it, they will come’.  The fact is that every successful opt-in based revolution from Google to Facebook succeeded because their authors understood and made a science of market receptivity, e.g. the socket.  We think of the Brin’s and Zuckerberg’s as geeks, but what they really got right was understanding what we were ready for before the rest of us even knew it.  Then they wrote the code.

Moreover, the ‘opt-in’ approach enjoys fullest play in the open marketplace.  By contrast, most organizations still prey on semi-captive audiences internally.  The cultural habits and behaviors (while similar in some respects and while generally converging) remain very different.  In the open market, customers seek change.  Inside an organization they mostly resist and resent it, probably because they just got used to being in the current place they don’t like very much.

As a consequence, while you may be able to identify a market (receptivity) and build for it externally, inside the walls of an organization you’d better be prepared to manufacture some consent.

That’s where transition management comes into play.  Engineering and creation of the ‘socket’ for change is usually a project whose complexity equals or exceeds that of the change itself.  And, it’s worth it.  Remember, the change doesn’t yield you a dime until people use it and accept it.

Creating the socket means a few basic things:

1. Understanding what will change
2. Identifying stakeholders and influencers
3. Understanding their relationship to the change
4. Clarifying and setting stakeholder expectations
5. Prepping stakeholders and shaping expectations
6. Targeting change delivery specifically to optimize against expectations

In the best of worlds, transition management sits at the coordinating center of a concert of processes all geared to deliver on some aspect of a successful change project:  change management, release management, risk management, deployment management, testing, evaluation, etc.  The specific coordination and focus it provides is that which sets all sights on stakeholder readiness and fulfillment.

Does it have to be big?  Not really.  It just has to stubbornly advocate for the readiness/receptivity aspect of change.  Though, in my experience, we do tend more often to underestimate what’s needed by way of transition management than the other way around.

So, the next time you’re about to embark on some grand undertaking or another, ask not what you can do only to make the change happen, but what you can do to make sure you’re ready to make good on it.

There are, however, a number of nuances around incident prioritization that may be worth reviewing and taking into account as you work to build mojo at your service desk. Arguably, the most important of these is the approach of tying initial incident priorities to the recovery SLAs as expressed in your service catalog. The service catalog of course describes services including the support available for services and the SLAs associated with recovery of services that fail.

In most cases, recovery SLAs within the service catalog can be grouped into a small number of tiers, thus making it easier to tie SLAs to incident priority. Too much complexity in a prioritization algorithm is generally unhelpful. In my experience, recovery SLAs for services usefully provide a starting point for urgency designations. Impact designations are more situational and tend to be driven by the extent to which a service has been disrupted, e.g. for one or many users.

One of the trickier aspects of using SLAs to drive prioritization involves deciding how to weight impact and urgency in a prioritization algorithm and how much to allow truly situational aspects of urgency to influence the algorithm. In very broad terms, information from the service catalog is usually best allowed to exert the most influence in urgency determinations. Situational factors less so. This has implications for the ‘spacing’ between urgency designations in the algorithm; urgency levels must be far enough apart to allow situational factors to influence urgency without bumping the end result into an adjacent level. Such determinations require attention to the specifics of each organization and its priorities. There are no hard and fast rules.

A couple of other basic points around prioritization merit mention.

First, priority is always relative. Incident priority is always priority relative to whatever elses is in the queue. There’s no such thing as absolute priority. The point of prioritization is to enable decisions about what work at hand is most important. The term ‘at hand’ is key here: priority is about comparing work that needs to be done, not about absolute importance.

Second, priority is dynamic. Priority can change as new incident enter the queue, as SLA boundaries approach, etc.

Third, priority is also fundamentally about work queues, not necessarily about the entire incident management process. In many cases, a single incident management process may actually consist of several work queues. Prioritization is about determining the order in which work is opened within a queue. Priority governs what happens before work is opened. After work is opened within a queue, decisions about how proceed generally fall to the support person or group handling the work.

Finally, the best prioritization schemes are mostly automated and leave little to the discretion of the support analyst. This makes complete sense when one considers that prioritization is a level one activity and is generally carried out by personnel having very little experience within the organization. Leaving matters to discretion or judgement usually leads to suboptimal results.

A lot of ITSM success is about what happens between processes, as much or more than it’s about what happens within individual processes. Incident prioritization is one such example. Here we’re linking incident management, service catalog management, and (of course) service level management. We’re using a relatively static process (service catalog management) to drive one of the most dynamic processes in ITSM: incident management. And, by doing so, we’re making good on the effort invested in building a service catalog to do much more than simply advertise services. Improved prioritization of incidents makes a real difference every minute of every day in most IT shops.

So, from a support perspective, what value do we get from defining technical services? What unique value do they offer a service management organization?

The answer is simple: Technical Services encapsulate performance commitments internal to the service provider. As such, they should map very closely to OLA’s (actual or planned) and probably also map very closely to support groups.

In considering the latter point, it’s probably safe to say that Technical Services can and should map EXACTLY to support groups unless some difference in performance is required for different services offered by a single support group.

Here’s an example. I have an application-based CRM service which is in turn supported by a number of technical services: network support, server hardware support, Windows support, application management, and data administration. But, upon closer examination, we see that both data administration and application management actually map to the same support group.

Does it make sense to continue to consider application management and data administration as separate services?

Well, unless there’s a different OLA attached to those two services, my answer (in the interest of keeping things simple) is probably not.

What purpose would it serve?

Clearly, ticket routing is going to be the same in both scenarios….only complicated (unnecessarily) by having two instead of one service.

What about reporting? Wouldn’t that be better supported by having both services in this example?

Well, probably not. We can already use other common fields such as incident/request categories to support reporting needs. We don’t have to use Technical Services for that purpose.

Again, the only really unique value offered is that Technical Services allow us to bundle up (encapsulate) performance commitments around one thing so that everyone downstream (business services and possibly other technical services) knows what they can depend upon.

In other words, we use them mainly to give OLAs a place to live.

This is a fairly arcane topic, but a lot of organizations put a lot of energy into Service Catalog modeling, often without a clear sense of what they can expect to get from their efforts. Modeling business services helps users understand and get what they want. Business Services also help the service provider be clearer about what it’s actually doing for users that’s actually useful. And, of course Business Services provide a home for SLAs. No services, no SLAs.

Technical Services define the known performance building blocks a service provider can draw upon to fashion dependable business services for end users. They give OLAs a place to live.

In practical terms, an organization with no OLAs and no plans for OLAs really has little to gain (apart from a general feeling of clarity) by modeling up its Technical Services. They won’t add much from a reporting point of view…at least not much that can’t be gotten elsewhere. Similarly, they won’t add any special magic to ticket routing.

So, a good starting approach for modeling technical services is to mirror them on your support groups and only elaborate them further if need or intend to wrap different OLAs around them…or if you can state a practical reason for otherwise making things more complex than they need to be!