All Posts in Leadership

|In: Leadership|Last Updated:

Despite the best (or perhaps worst) efforts of the business and IT press, words do have meaning and, depending on the word, at least a small population of loyalists who remember the meaning and cringe when it’s ignored in favor of some other, vaguer usage.

Take “Return on Investment” — ROI. Originally a collection of related mathematical formulas designed to take into account the impact of interest rates, depreciation, taxes and other factors on a financial investment over time to establish its monetary value in current dollars, ROI is now usually used to mean “good.” What had been a precise meaning has become indistinct.

In IT we have our own culprits. This week’s stalking horse is “service level.” Because there are those among us who equate additional syllables to increased impressiveness, service level is used far too often to mean “service,” as in, “we need to improve our service levels.”

Stop. Please.

Services are what you provide. If you need to improve a service you provide, please do so. Service levels are a technique for measuring your success at providing them. When you say you need to improve service levels you’re saying the measure is what matters rather than the mission.

Not that service level measurement is a bad technique. Quite the opposite: It’s a workhorse method for assessing how well an organization meets its commitments in delivering a service. So just in case you haven’t been inculcated into the mysteries of service measurement, here’s a quick tutorial.

A service level is a two-part measure. That’s what makes it so useful. The first part defines some service target you’re trying to achieve. Perhaps it’s the response time for a call to the help desk that’s been escalated. You might set a service target of two hours.

It isn’t reasonable to imagine you’ll meet or beat that target every time. The world happens and events intervene; the demand for escalation services is determined stochastically, not deterministically. Which leads to the second part of service level definition: How often you meet or beat the target, established as a second target. Which is to say, you might establish a service level for help desk escalation that says users will get a callback or visit within two hours 95% of the time.

This is a useful way to measure quality of service delivery. The problem is that the establishment of service levels has become an unquestioned tradition in IT: That we should define service delivery goals in terms of a service target and a commitment on how often we’ll meet or exceed it is assumed rather than decided upon. Which is to say, IT now starts with the measure and works backward to establish the organizational goal. And once you establish service levels, what could be more natural than to establish a service level agreement (SLA) … a contract … with your business counterparts, formalizing your commitment.

SLAs are popular among IT practitioners. Every survey I’ve seen assessing their utility among business users of IT services suggests they’re pointless — something IT wants to do and business users go along with, right up until they don’t get what they want when they want it. Also … note that when you establish a formal contract of any kind with your business counterparts you’re defining your relationship with them to be that of a service provider with internal customers, which is an invitation to be outsourced.

Should you be sufficiently adventurous that you don’t want to automatically define your goals in terms of service levels just because that’s what everyone else does, here’s an alternative: Define your goals in terms of continuous improvement. That leads to a different, statistical pair of measures: The mean and standard deviation. Which is to say, measure response and calculate both the average response time, and the extent to which responsiveness varies from instance to instance. Establish this as a baseline and decide how much the average should improve and variability diminish over time.

I don’t know if that’s the right goal for you or not. Perhaps it makes more sense for you to define a target and the frequency with which you’ll meet or exceed it.

What I do know is this: You have to start with the goal, not the measure. Otherwise you aren’t leading, just following tradition.

Comments

|In: Leadership|Last Updated:

“When I am right, no one remembers. When I am wrong, no one forgets,” Doug Harvey, a professional baseball umpire, once lamented.

In IT we face a similar dilemma: Our responsibility is the delivery of working software that adheres to the specifications. When we do, and the specifications are appropriate, and the business makes use of the software to its fullest capabilities, and everything improves the way it was supposed to, the rest of the business takes it for granted. Or even worse, it grudgingly acknowledges that for once IT did something right, making it clear we shouldn’t feel too good about this victory.

There is no such thing as an IT project. It’s always about business change. When the business change isn’t successful, we both know what happens next: No matter what really went wrong, IT will get the blame. Why? Because it’s always safe to blame IT. We’re convenient scapegoats for everything that can (and usually does) go wrong in a project.

And there’s nothing we can do about it. Our job, after all, is done when the software works according to the specifications. Everything else that has to happen is someone else’s responsibility.

Right?

Right … if, that is, you practice the Theory of Else.

The Theory of Else, whose practitioners hold the word “they” in high esteem, asserts that it’s better to determine who else should have done something different than it is to determine what you can do to ensure success.

In many IT organizations, the Theory of Else is ingrained in the culture: “The software met the specifications. It isn’t my fault that the specifications were wrong.” “The software can do what the business needs it to do. It isn’t our fault that the business failed to use it the way we designed it.”

Heck, some IT organizations missed most of the new economy, figuring it was someone else’s job to figure out that e-commerce was important. IT’s job? To build software that met the specifications once they did.

If you can get away with the Theory of Else, more power to you. There’s no particular nobility in doing somebody else’s job for them, and there’s a lot of safety in building software that works just fine only nobody in the business ever puts it to the test.

More than likely, though, the Theory of Else will work for everyone else in the business, leaving you holding the bag. In their eyes, these are all IT projects, so if they don’t deliver the expected returns, it must be IT’s fault.

Which means IT has to practice a different theory — the Theory of Everything Else. The Theory of Everything Else leads to this IT mission statement: “We do whatever needs to get done that nobody else chooses to do.”

It might not be elegant. It falls a few parsecs short of being diplomatic. But it has two useful consequences.

The first is that it’s a turf intrusion. If, for example, nobody develops a communications plan, the most likely result is that employees will resist the planned change strenuously, causing it to fail or at least disrupting its success. So instead, imagine you practice the Theory of Everything Else and develop a communications plan for the affected employees.

“Who do you think you are! That’s a job for Internal Communications, not IT!” or so you’ll most likely hear from the head of Internal Communications, who thereby volunteers for the job.

Likewise business process redesign: “Who do you think you are! That’s our responsibility,” you can imagine the Chief Operating Officer exclaiming. Which, of course, it is, again letting you off the hook specifically because you carefully put yourself on the hook.

You’ll undoubtedly step on some toes by practicing the Theory of Everything Else. Which brings us to the second benefit: While you might step on their toes (yes, there is a pun there, but only if you insist), which might cause some resentment, that’s far better than the alternative.

Which is, of course, being on the wrong side of their Theory of Else.

Comments