Some magazine or other once asked me to identify the biggest barrier to computer telephone integration (CTI). “No logical organizational sponsor,” I replied. “Telecom managers see it as just another headache, IS directors figure it’s telephone stuff, and call center managers see it as the devil’s tool since callers will have to interact with technology.”

It was a good answer, but wrong. Lack of a sponsor (now a non-issue) was reason number 2. The biggest obstacle to CTI, then and now, is PBX reliability.

PBXs deliver “five-nines” quality — they work at a 99.999% service level. That’s good, and it’s why telecom managers do well running data centers — they don’t think downtime is normal.

It’s also bad, because as long as your PBX continues to deliver dial-tone, explaining why you need a new one is hard. Old PBXs don’t support CTI, though, so they, rather than lack of sponsor, are the biggest obstacle to its implementation.

We’re continuing with our series on creating an integrated IS plan. This week we focus on the company’s operational goals — perhaps “infrastructural” is a better term, or “pain-in-the-neck”. Dial-tone delivery is an important operational goal. So is messaging (voice mail, e-mail, fax), collaboration (groupware), and support for general office tasks (word processing, spreadsheets and so on).

Everything about figuring out operational goals is awkward. Setting concrete goals is hard, calculating payback is impossible, and getting the executive suite interested in discussing anything about the subject other than cost is almost embarrassing since they expect you to be thinking strategically.

The basic question, which can only be answered in the executive suite, is one of lifestyle. We’re dealing with the basic furnishings of day-to-day work life. Over the years we’ve learned two basic lessons: (1) Eventually every desk gets one; and (2) There’s a ratchet effect — you can add items to the list but you can’t take any off. Lifestyle reduction is hard — once you own two cars, going back to one is demoralizing.

The basic lifestyle question is for you what benefits is to human resources. There’s no demonstrable ROI or benefit to the P&L, but the company has to do it anyway. It may not be value-adding in the accounting sense, but not doing it is value-subtracting so you’re stuck.

Settle the basics in the executive suite, then move on to the next agenda item. As CIO your personal focus should be on value-adding activities, so delegate the detailed planning to an up-and-comer who wants it and can get enthusiastic about it (your Information Center manager?), teamed with your data center/network manager.

The plan itself includes a few key elements:

  • Lifestyle description — little more than a list of the key tools you’ll be providing and supporting. This list should be by category (telephones, e-mail, groupware). You’ll deal with specific products and standards later on, in your technical architecture plan.
  • End-user interest group — a collection of power users, end-user technology thought leaders, and PC mentors. It should meet monthly with your Information Center manager, and be closely involved in your planning and priority setting. It’s an invaluable resource.
  • End-user support plan — giving employees a great toolkit and then cheaping out when it comes to helping them use the tools is dumb. Be sure to balance the need for support with a goal of self-sufficiency, though, or you’ll create a bottomless money pit.

That’s about it. Added to the strategic and operational goals we’ve planned for over the past few weeks you have validated, consensused, syndicated, and generally spread around your thorough understanding of what your company needs from information technology.

All that’s left is doing something about it.

According to my daughters I have a bald spot the size of Jupiter. They delight in informing total strangers of this – a major source of glee. They are, of course, the primary cause of my scalp’s increasing visibility. Knowing this hasn’t instilled even a slight level of guilt, I’m sorry to report, but it has increased their interest in Rogaine ads.

Even before I had kids, though, I’d started down the hair-loss path. It was responsibility for allocating IS resources that started the follicle damage.

This is the third article in our occasional series on creating an integrated IS plan. The last two talked about linking to your company’s strategy. This week we’ll help our companies survive until the future gets here by dealing with tactical issues. (As we’re using the terms, strategy changes the company’s business model – how it thinks about its products, customers, processes and how they interrelate. Tactics, in contrast improves how it accomplishes its current business model.)

At a tactical level you deal with two basic questions: What projects will most improve the company’s core business processes, and how should you allocate resources to get them done?

I’ve seen four basic ways of answering these questions. One is really stupid – make all the decisions yourself in a vacuum and inform the rest of the company what you’re going to do this year. If that appeals to you … well, it’s been nice having you as a reader, and best of luck in your job search.

The first good way to set priorities is to form an IS Steering Committee – really, the heads of your company’s business units, meeting to agree on the company’s IS project priorities and resource allocation. Your role is to set the agenda and facilitate the meeting; their role is to make the final decisions. If everyone agrees to this approach it simplifies your life, because who’s going to argue with what everyone signed up for?

IS Steering Committees also help you reserve resources for strategic projects, and help integrate projects so the company gains maximum advantage from its investments in information technology. When you can make them work, IS Steering Committees are the way to go.

IS Steering Committees fail in two circumstances. The first is entirely your fault – if you miss some significant projects, the committee will allocate all your resources without accounting for all the work you have to do. Solution: Don’t do that. Ask your leadership team to participate in setting the agenda and you’ll get it right.

Here’s the second reason IS Steering Committees may not work: Sometimes a company is too diversified, lacks a strong enough focus, or is too politicized for the group to come to consensus. You can’t control this, but you need to be savvy enough to predict it – don’t form an IS Steering Committee if you don’t expect it to succeed.

If this is the case, go to Plan B – proportional resource allocation. Under Plan B you allocate your developer and maintenance IS headcount to the business units in proportion to their headcount, budget, or political importance. You then work independently with each business unit head (or, one of your managers works with each of them) to figure out the projects each group will work on. If a business unit wants more than you can provide with the resources you’ve allocated, it’s free to allocate some of its own budget so you can hire contractors or additional staff, or to sponsor an IS budget increase.

Be careful of Plan B, though, because it can turn into Plan C in a heartbeat. Plan C is to break up IS, distributing it among the business units. And although this occasionally makes sense, especially for very large, diversified conglomerates, it pretty much relegates IS to a tactical role, because strategic projects rarely respect current organizational boundaries.