All Posts in Policies and Procedures

|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: Organizational Design|Last Updated:

According to the Theory of Else, IT’s job is done when the software runs. It’s up to others in the business to make sure useful business results follow.

As last week’s column explained, the Theory of Else is a good way to make sure IT gets the blame when projects fail to deliver their expected value. The alternative, the Theory of Everything Else, is what will see you through to success: IT has to take on whatever tasks nobody else in the company is willing to do — not because it’s IT’s responsibility, not because it’s “the right thing to do,” but for the simple and unavoidable reason that your other alternatives are worse.

One of the most frequent items in the everything else list is the redesign of one or more business processes. And while it might seem counterintuitive, IT is a logical home for the discipline of business process redesign, for two very different reasons.

The first is that since IT is involved in every business change — something that isn’t true for any individual business division — placing the discipline inside IT means its practitioners will have the opportunity to practice their craft more than once, letting them deepen and perfect their skills (the same, by the way, is true of project management).

That’s the organizational logic. There’s also the knowledge of the process design discipline that already exists inside IT. No, I’m not talking about your business analysts, although some of them might have built some abilities along these lines. It’s your network engineers who really understand the subject, because everything you ever needed to know about business process design is already built into TCP/IP.

What TCP/IP does is break a message into chunks, send them into an intrinsically unreliable network built out of a collection of store-and-forward queues, to a defined destination where they’re reassembled into the original message. Ignore the break-a-message-into-chunks bit and what’s left?

A pretty good representation of most business processes, that’s what. Business processes consist of work queues. A piece of work is pushed onto a queue where it waits its turn. When its turn arrives, the queue manager does whatever is required, then forwards its completed to the next queue, where it’s worked on in its turn.

That isn’t very different from the routers that make up a TCP/IP network, although the routers don’t do much to each packet other than check it for errors and then either forward or discard it.

Any given link or router can lose a packet, which is to say, the network is intrinsically unreliable. That’s the IP part. The responsibility of the TCP part is to detect when that happens and correct the problem.

In a work process, work can get lost moving from queue to queue, too. A well-designed business process includes error checks to make sure work doesn’t get lost, assuming that from time to time something will go wrong along the way. Same thing.

Network engineers understand they have to deal with two different measures of speed: Latency and bandwidth, which is to say the end-to-end transmission delay for a single packet, and the total amount of information the network can handle in a given period of time.

Business process designers need to consider both cycle time and throughput — same ideas, different words.

To improve network latency and end-to-end bandwidth, network engineers find and speed up bottlenecks. Speeding up a part of the network that isn’t a bottleneck achieves nothing — installing faster routers is pointless if the ones you have already outpace the speed of the connection that links them. Business process designers also need to look for process bottlenecks instead of just speeding up whatever process step is most easily accelerated.

Network engineers are accustomed to the concept of a management console — a display that lets them know, at a glance, the health of the network. Manageability is built into the design of every router to make network management possible.

How many business process designers have the same understanding? Yes, it’s easier to manage a router than an employee. It still isn’t all that hard to build manageability into the queues that make up a business process, and construct a dashboard so the process manager can tell, at a glance, the health of the process.

Can a network engineer really succeed as a business process engineer?

Beats me. It sure would be fun to facilitate the design sessions, though, don’t you think?

Comments