All Posts in Policies and Procedures

|In: Organizational Effectiveness|Last Updated:

To get my PDA working properly I had to change my e-mail address. It’s an irritating story.

I’ve been using CompuServe 2000, an IMAP e-mail platform, with Outlook as my e-mail client. Everything worked fine … most of the time, anyway … until my recent change in employment, which moved my calendar from my office copy of Outlook, which was attached to Microsoft Exchange. My PDA (a Palm device) synced just fine to that, but not to my home copy of Outlook. The problem: I’d installed Outlook using the “Internet only” installation option, but synchronization requires “Corporate/Workgroup” installation instead.

So I switched over to Corporate/Workgroup and voilà! … CompuServe 2000 stopped working. Some genius at Microsoft decided IMAP e-mail should only work in Internet only mode. Which means CompuServe 2000 (along with all other IMAP e-mail services) and PDA synchronization are incompatible.

Please note my new e-mail address.

While annoying, the experience was also timely, because I was in the throes of helping a client select an e-commerce vendor. As with most vendor evaluations, we asked questions, made note of the answer, and compared the vendors on the basis of their responses.

Were I to evaluate PDAs and e-mail systems this way, I’d have easily reached the conclusion that my PDA, e-mail provider and e-mail client would work together in perfect harmony. The incompatibilities were, after all, buried pretty deep.

Which leads to a suggestion: Follow all vendor selections with a pilot implementation. The ideal pilot is simultaneously technically challenging, small in scale, and politically simple. You’re looking for a relatively small group that’s enthusiastic about the new technology — you’ll have plenty to worry about without dealing with resistance to change –that will exercise it hard to test as many complexities as possible.

This should be obvious, but for one reason or another … go-for-broke schedules are a common culprit … companies often skip the pilot. They invariably lose more time than they ever hoped to gain, because problems are easier to fix under controlled circumstances.

That’s one tip. Want a few more?

Tip #2: Be balanced. I divide evaluation criteria into four categories: Technology, Services, Business/Marketplace, and Pricing. With technology, don’t try to design the vendor’s product. You’re watching out for bad architecture, reliance on immature or fringe platforms, and obsolescence, and checking whether the vendor will commit to service levels. To define the others: Services covers features and functionality; Business/Marketplace helps you predict whether your vendor will in business next year; and Pricing covers not just the price itself but the pricing structure.

Tip #3: If you can make your decision from the numbers, somebody rigged the evaluation. Use a three-point weighting factor for the evaluation criteria, where 1=Useful, 2=Important, and 3=Crucial. Score responses on a five point scale (with no fractions!). When you tote everything up, scores within 5 percent are a tie. If one vendor is the clear winner, you either compared the preferred vendor to only its weakest competitors, the preferred vendor provided the evaluation criteria, or both. The numbers screen out clearly inferior choices. Use the details of a vendor’s responses, and the tone of each conversation (I prefer interviews to written responses) to differentiate among the remainder.

Tip #4: Watch out for second-stage selling. Every losing vendor will ask you where they came up short. If you answer the question you’re in for an argument. Your correct response is something like this: “You didn’t lose on any single question. We were confident your solution would have worked, but in balance it wasn’t as good a fit for our needs as our first choice. To give you any more detail I’d have to violate the confidentiality of the other vendors we talked to, so I’m afraid that’s a much information as I can provide.”

Tip #5: Don’t worry. Be happy. You’ll never know if you picked the best solution, even after you’re operational. No matter how good an evaluation you performed, you’ll run into gotchas during the pilot, and more during the full roll-out. If they aren’t insurmountable you made a good choice, so don’t fall into the grass-is-greener mentality.

Remember token ring vs Ethernet? Both led to headaches during implementation, but in the end, either net worked. That may be a wisecrack, but I doubt it.

Comments

|In: Industry Commentary|Last Updated:

Who wins when one company acquires another?

The shareholders do, of course. The point isn’t to impoverish the owners.

The acquiring company ought to win too, as measured by profitability and marketplace success. That, in fact, ought to be the reason for any acquisition. Whether the goal is increased economies of scale, elimination of a competitor, acquisition of customers, acquisition of skills or technology, or product line extension, the acquiring company ought to be stronger following an acquisition than it was before.

Guess who doesn’t normally win. The acquired company is one answer. It might benefit, but there’s no a priori reason to expect it to. Individual employees aren’t usually beneficiaries either, whichever company they started with.

Corporate acquisitions and large IT outsourcing deals are similar in many respects, with the outsourcer playing the role of acquiring company. That means it’s the only entity certain to benefit from the transaction.

How about the company that decides to outsource its IT? That’s a more complicated and uncertain question. The proponents of IT outsourcing rarely promote direct financial benefit anymore. As explained in last week’s column, an outsourcer can only reduce its client’s IT costs by reducing the amount of service provided, unless the IT organization being outsourced just wasn’t very good at the job.

So instead outsourcers talk about letting a company “focus on its core competencies.” This logic is something short of compelling. After all, from the CEO’s perspective the only differences between managing a CIO and managing an outsourcing contract are (1) unlike internal IT, outsourcers need to make a profit; (2) outsourcing contracts are likely to have loopholes beneficial to the outsourcer, and the outsourcer has much more experience negotiating outsourcing contracts than the CEO does; and (3) it’s a lot easier to replace a CIO than an outsourcing company.

So why do CEOs sign major outsourcing deals? The most likely answer is far simpler than the textbook ones: They’ve given up on internal IT. They buy outsourcing because in their eyes in-house IT botched the job and can’t be fixed. Their eyes are the only ones that matter.

Since an outsourcing decision on the part of your company is unlikely to advance your career, what steps can you take to prevent it?

Here’s one: Don’t botch the job. Let’s start with IT operations, since in most companies this absorbs more than half the total IT budget, making it the biggest outsourcing target.

Do you adhere to or improve upon industry best-practices? (Of course, if you don’t know what they are, the chance of improving on them is slim.) For an excellent source of information on this subject, check out the Information Technology Infrastructure Library (ITIL — http://www.itil.co.uk/). It’s the industry standard reference point, and friends who are experts in the field tell me it’s the right starting point for IT operations processes.

IT operations is where formal measurements work best, because it’s where you do the same things repeatedly. If you haven’t established formal service level measures, do that immediately. Implement a continuous improvement program for the most important of them, usually the stability and performance of specific, critical applications. You might be tempted to measure only platform performance and stability “because that’s all we have control over” but that would be a huge mistake. If a major application is down, nobody cares except your troubleshooters that the servers are up and running, after all.

Track service levels, but don’t negotiate them. The process of negotiating service levels provides no benefit and carries plenty of risk. There’s no benefit because no service level worth your time to negotiate will truly satisfy anyone. Regardless of what you negotiate, anything short of the telephone, where you always get dial-tone and always get it right away, will fall short of what’s wanted.

Here’s the downside: Negotiating service levels means you’re negotiating with the rest of the business. That separates you from everyone else, makes you look and sound like a service provider, and establishes precisely the gap between what you provide and what they want. It’s another way to make them customers and yourself into just another outside supplier. As mentioned last week, that eases the transition to an outsourcer.

So remember: Tracking service levels makes you professional. Negotiating them simply makes you vulnerable.

Comments