All Posts in Organizational Effectiveness

|In: Leadership|Last Updated:

Here’s a common question: “Should we be using Linux?”

I have a standard answer: “I have no idea.”

As described last week, vendor/product decisions are social beasts, best addressed through the When/Who/How/Why/What formula. Determine when you have to make the decision, who should be involved, and how you’re going to make it. If everyone commits to “How” — that is, to the process you’ll employ in making the decision — then you’ll be able to reach consensus on why it’s important and what the organization should do.

“How” — the decision process itself — is the real work of the formula and this week’s subject. Since Linux triggered this discussion, our focus will be on platform-layer decisions. Application-layer decisions are similar, although with much heavier involvement on the part of the end-user community. It’s a seven-step process.

Step 1: List about five candidate products and vendors. It should be a diverse list, including both mainstream and wild-card candidates. (Avoid the popular practice of creating a rigged list so you can just go through the motions.)

Step 2: Determine the important features. In the platform layer, this mostly translates to applications and services. Make this list generic (“directory service”) rather than product-specific (“NDS”). Include price as a feature.

Step 3: Establish integration requirements. For database servers, you may specify ODBC compliance. For servers you may require compatibility with your data center management system. Just as new employees must be able to fit into the team, so products must be able to fit into the network.

Step 4: Specify vendor requirements. List what matters to you, not the vendor’s internal characteristics. Availability of experts and third-party enhancements matters. The potential for a product becoming an orphan matters. Quality of support matters as well. And, there’s the vendor’s announced plans for the product. The vendor’s financial strength and the product’s market presence may lead to something that matters to you but they themselves don’t.

Step 5: Establish scoring criteria. For example: When listing key applications and services you used generic terms. If support for specific applications and products matter, give higher scores to products that provide it. Built-in services may rate higher scores than third-party solutions. And so on. The key: Know how you’ll score features, integration requirements, and vendor characteristics before you do any research, not after.

Step 6: Blend requirements into a single list and assign weightings to each item. Use a three-point scale: 3 is a deal-breaker, 2 is important, 1 is useful. If the group is small, assign the weightings through group consensus. If it’s a big group, consensus is too unwieldy so you’ll just have to vote on it: Give everyone involved a fixed number of 3s, 2s and 1s to vote with and tabulate the results.

Step 7: Gather data. Read product comparisons, talk to the vendors, issue a request for proposal if you must — and use it to score the products.

Step 8: Pick the winner. Remember, though, this scoring system isn’t precise. If the top product scores 132 and the next in line scores 128, they have tied. Also remember, vendors have been known to exaggerate, so run a pilot with the top scoring candidate (or the top two if they’re close) before making a final decision.

Now … how does Linux fit into this process?

Very nicely, if you handled Step 4 properly. With an open-source product, support is entirely through third-parties (something true of many traditional products as well), the product evolves by duplicating successful innovations of commercial competitors, and the personal commitment of its advocates is part of the question of potential orphan-hood, but the vendor issues that matter to you are the same.

Product and vendor decisions easily become emotional issues. The way to combat this is for everyone involved to attach their emotions to the selection process instead. Do it by the numbers and you’ll make a good decision. Most important of all, it will be a decision everyone can support.

Comments

|In: Leadership|Last Updated:

Have you ever searched for just the right word, failed, and used the wrong one instead?

I did in my New Year’s column awhile back, using “progress” to mean “evidence the world is moving as I predicted.” Some readers understandably interpreted “progress” as “approval” instead. Not so. In fact, I find some of the trends I anticipate distasteful – predicting them is no more an endorsement than is a meteorologist’s forecast of hazardous weather.

An example: I predicted that Linux would become “just another Unix,” spoiled by its own success. Many in the Linux community disagreed with me, politely but firmly. For the record, I hope they’re right and I’m wrong.

If you’re a Linux fan, your team is rising in the standings. That’s really nifty, but as an IS manager you aren’t playing fantasy baseball. You’re choosing products to fill gaps or replace other products in your technical architecture. Regrettably, product and vendor selection isn’t a widespread skill among IS professionals. It should be, though. Most of us buy when we can and build when we have to, so we ought to be the nastiest power shoppers around.

The past two weeks we looked at how to pick future winners in the technology marketplace. This week we address a related, but very different, question: How should you go about choosing products and vendors for your own success?

Here in the IS Survivalist Compound we recommend the When/Who/How/Why/What formula. (No, not Who/What/When/Where/Why/How. That solves a different problem.) Too many IS managers just want to be right, forgetting that product decisions are social enterprises. Skip the socialization steps—most of the formula—and at the first sign of trouble you’ll find yourself dangling all alone at the end of a rope, twisting slowly in the wind.

Here’s how the formula works. You start with “When,” as in “When is the real deadline?” When you make technology decisions you want to make them as late as possible, because products and vendors change pretty quickly. Sometimes, however, you do have the leisure of planning.

Who is next. Ask whose decision this is. It’s a multiple choice question. Don’t just look at the organizational chart. Figure out who’s likely to cause trouble if they don’t like what you select. Invite them, or someone who can represent them, to the party – the kickoff meeting.

A suggestion about preparing for the kickoff: Do some social engineering up front. Spend some one-on-one time up-front with influential members of the group, sharing your goals for the meeting up front and enlisting their support.

At the kickoff meeting you’ll have too many people in the room to do any actual work. That’s fine. Stakeholder meetings aren’t for getting work done. They’re for ratification and socialization. What you need to accomplish in the kickoff meeting is to get everyone to commit to “How” and “Why.”

“How” is the process the work team will go through to reach a decision. Big groups can’t do effective research and decision-making. Since the actual work must be done by a small team, you must give the stakeholder group a sense that it remains in control of the decision without letting its members control the day-to-day work. The best way to achieve both goals is to describe a thorough, professional product selection process, with periodic checkpoints back to the stakeholder group.

Good processes lead to good decisions. Get each stakeholder to commit to the process and you’ll be in a position to make a decision the organization can live with. This is especially true because it is the members of the stakeholder group who will articulate “Why” – why this decision is important, another way of asking what the business need is for the product.

Then, all that’s left is “What” – what product the team selects as the result of the process.

We hand-waved over the actual decision process this week, even though it orchestrates all the real work. We’ll cover that topic next week.

Comments