All Posts in Office Politics

|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

|In: Leadership|Last Updated:

Humans choose sides and hate the other. It’s built in. Ethnic groups deprived of outside disdain fragment into ethnic subgroups that insult each other. Religions deprived of religious persecution fragment into religious factions that persecute each other. Minnesotans tell Iowa jokes.

A business deprived of strong competition isn’t immune to this human tendency either – it fragments into departments whose members make snide comments about each other while their managers vie for budgets and other resources. If you want to see an example of this, chances are the only tool you’ll need is a mirror.

I received a bunch of mail following a recent column recommending that IS establish multiple PC standards based on different kinds of work habits. Most of my mail makes it clear that lots of IS professionals still view the rest of the business with disdain and classify end-users into three groups: Idiots, troublemakers, and what was your name again?

Before you accuse me of IS-bashing and throw aside your issue of InfoWorld in disgust, ask yourself this: Do you or your analysts tell dumb-user stories? If they snicker at white-out on the screen, photocopied diskettes, and mistaking an answering machine for a modem, you have a problem.

Do your end-users snicker at the “Helpless Desk,” call outside consultants instead of IS analysts, and sneer at your pocket-protector-wearing chip-heads? If so, you have a problem, and if you don’t know whether they do or not you have a bigger problem.

As an industry we tend to focus on technologies to solve our problems, and when technologies alone aren’t enough we apply new methodologies or write new policies and procedures. Throwing technologies, methodologies, and policies into an atmosphere of mutual distrust has a predictable result: Zilch.

The psychological cause of the mutual distrust between IS and the rest of the business is the same xenophobia that afflicts us socially and internationally. Fortunately, within a corporation it’s curable.

How? Glad you asked. Here are some concrete actions you can take to create a cooperative atmosphere between IS and the rest of the company:

Trust-builder No. 1: Don’t be part of the problem. It’s easy to instill loyalty and esprit de corps by fostering an us vs. them attitude. Often, the process is unconscious. Watch your own behavior. Never disparage other parts of the company.

Trust-builder No. 2: Stamp out the word they. Insist on we: “They haven’t told us what they need,” becomes “Let’s figure out what we need.” If you can’t use “we” you don’t have the right people in the room. Get them there, or at least put a name on whatever part of “they” doesn’t turn into “we.” “They won’t let us do what we need to do,” becomes “How do we persuade Jim Smith of what we need to do?”

Trust-builder No. 3: Foster mutual problem-solving. “You” becomes “we,” too. “You need to do this,” becomes “We need to do this.” Include both end-users and IS professionals in your teams so it’s always “we.” Working together builds trust.

Trust-builder No. 4: Don’t allow blame. Don’t allow its synonyms, either. “Who caused this mess?” is usually a waste of everyone’s time and energy. “How do we fix it?” takes care of problems and builds trust in the bargain.

Trust-builder No. 5: Replace requirements with design. When you determine requirements, you ask, “What do you need?” When you design you ask, “How can we make this work?” It’s a joint effort now. You’re a partner, not just taking dictation.

Trust-builder No. 6: Foster xenophobia. People distrust members of other groups. You can’t eliminate this very human tendency, so exploit it instead. “How can we make this work?” becomes “How can we turn this into something that helps us beat those schlemiels over at the XYZ Company?”

Distrust between IS and the rest of the business is bad and getting worse. Whose fault is it? See trust-builder #4 for the answer. What’s important is that you … sorry, we … need to fix it. It’s our job.

Comments