"We want to build a better partnership with the business."

"We want to get the business more involved in IT decisions."

"We want to make clients feel that this is their project."

"We want to be customer-focused and show that we're listening."

For any number of reasons, and always with the best of intentions, IT executives form "steering committees" comprising business and IT leaders.

And more often than not, the results are disappointing. I've heard a multitude of complaints.

Some are relatively benign. For example, executives are terribly busy; so after the first meeting, they delegate attendance down to a level that has little real authority in their business units.

Other complaints are far more serious. For example, instead of helping IT achieve its objectives, sometimes steering committees morph into obstacles that exercise power over IT -- authority without accountability, a classic violation of the golden rule of organizational design. In extreme cases, steering committees get headstrong and demand the right to micro-manage IT, even to the point of getting involved in technical directions and internal decisions such as IT infrastructure.

Even when they're relatively manageable, steering committees often become a bureaucratic waste of time with little added value.

Sometimes, the very presence of the steering committee may confuse issues. The committee's concurrence may lead IT staff to think they have clients' support, when the real decision-makers have not yet agreed.

Am I being overly cynical? Come on, tell me that you love going to your steering committee's meetings!

What Goes Wrong

Don't misunderstand me. I'm not against all committees. It's just that most of the IT steering committees I've seen do more harm than good.

Why do well-intentioned committees go wrong? It seems to come down to two mistakes: Committees are formed for the wrong reasons. And committees are formed without a clear purpose.

Before looking at the right way to form a committee, let's consider these two mistakes.

1. Wrong Reasons to Form a Committee

Here are some examples of reasons not to form a committee:

To gain access to business executives: Believe it or not, I've heard people offer this as a reason for their committees. Isn't it obvious that if you have something to say that's relevant to business executives, they'll grant you access to their calendars? And if you don't, you can be sure they won't show up at committee meetings. At best, you'll get their #2, or #3, or....

Access to business executives depends on their perception of your value to them. Forming a committee doesn't, in itself, make you relevant or get you that access.

To gain support for IT initiatives: If IT has an initiative that it's trying to sell the business, a rubber stamp from a committee is unlikely to hold any value whatsoever. A business executive who doesn't buy in isn't going to magically support the project because IT's committee said to.

The first question here is: Why is IT trying to sell the business on its initiative. If projects are not client-sponsored, cancel them! This maxim includes ERP. It's futile for a CEO to command IT to implement ERP over the objections of business units. See my column on common business processes for more on this.

If the initiative is truly appropriate for IT to sponsor (like infrastructure which IT owns in order to supply services to clients), then IT needs to convince its chain of command, not its clients. When AOL needs capital to buy more servers, it makes a pitch to its bank, not its subscribers. And it convinces the bank with a business proposal based on market research, not a committee of subscribers who like the idea.

A committee is not an effective substitute for ensuring that the sponsorship of projects is in the right place, or for selling the right people on IT initiatives. And if you fail to sell the right people, the committee's blessing won't cover your backside.

To gain greater business involvement in IT: Involvement in what decisions? Are committees established to encourage clients and IT to meddle in each others' businesses, as if this is what a good partnership is all about?

Let's get back to the basics of the business-within-a-business paradigm. Clients decide what changes they'll make in their businesses, and what to buy from IT. IT decides what projects to bid, what alternatives to offer, and how to go about delivering its products and services.

An effective partnership is not a result of each meddling and disempowering the other. Great partnerships occur when IT offers services that help clients, and clients agree to buy them -- in a mutually respectful customer-supplier relationship.

I'm not talking about being a passive order-taker. IT can be very proactive by helping clients discover strategic opportunities for IT, by offering technical alternatives and helping clients understand the risks and trade-offs among them, and by engaging clients in the design of the look and feel of solutions.

You don't need to form a committee to work closely with specific clients on any of these legitimate interactions. But a vague purpose like "involvement" invariably leads to confusion about authorities and stress for all involved.

To communicate better with the business: Communicating regularly and well with clients is a great idea. But it's a waste of time to set up regular communications sessions with everybody at once, and then try to fill up the agenda with something useful each month.

Even if you have things to say to clients every month, there's no guarantee that the committee will include the people you really need to talk to about those specific issues. And there's certainly no guarantee that the most effective way to talk to clients about any particular issue is all at once (rather than one-on-one).

The truth is, you don't need a committee to talk to people. A better solution is to schedule a meeting (or a series of private meetings) with just the people you need to talk to -- when you have something to say.

Keeping clients informed may not even require a meeting. According to Meyer's Rules of Order, you should only schedule a meeting when the communications is to be two-way. If all you need to do is announce something, don't waste people's time; just put it in an email, newsletter, or video.

To approve decisions made by staff: A committee of executives may be formed to "bless" decisions made by people at lower levels of the organization.

A common example in IT is architectural standards. The appropriate technology experts (and, hopefully, other stakeholders) convene to discuss a specific standard. The list of experts and stakeholders varies based on the standard being discussed. After some research and discussion, they come to consensus on a standard.

At that point, their decision may have to be approved by a committee of executives. Of course, rank doesn't make one qualified to judge such a decision. Committee members rarely have the technical depth needed to understand the issues, and generally do little more than rubber stamp the choice already made.

In other cases, the experts and stakeholders may not agree, and they may turn to the executive committee to break the log-jam. If the committee does so, a faction of disappointed stakeholders will be expected to comply with a standard they don't support. The organization will face a long battle to gain compliance, simply because it used a committee to decide instead of forcing the stakeholders to work until they reached true consensus.

Executive committees whose purpose is to question and approve decisions made by the people most qualified to make them are a form of disempowerment, and reinforce a bureaucracy driven by rank rather than competence.

2. Vague Purpose

The second common mistake is to form a committee with a vague purpose, like "to guide strategic IT decisions."

With an unclear charter, nobody knows why they're there. These committees don't focus on the value they're supposed to deliver, because they don't know what that is.

In parallel, IT staff don't know when to involve the committee. They often err on the side of safety and run everything through the committe, which of course slows everything down unnecessarily.

In addition to being a waste of time, badly chartered committees often wander into areas they don't belong in, and become bureaucratic obstacles rather than effective means of consensus. These committees disempower IT staff, slow innovation, blunt IT's entrepreneurial spirit, and make poor decisions that they're not qualified to make.

Types of Committees

If you've made it this far through my tirade, then I owe you a constructive view of committees.

First, let's clearly define the term. A committee is a permanent body, not a project team that disbands when the project is completed. It has a fixed set of members, best defined in terms of the organizations represented rather than the names of individuals. And generally, it meets regularly.

Everybody knows the old joke, "a camel is a horse designed by committee." It speaks to a basic truth: Committees are a cumbersome way to make decisions.

It's hard to manage the dynamics of a big group of people. It's hard to get consensus. It's even tough to schedule meetings and get everybody to show up!

Committees aren't good in and of themselves. They should only be formed when they're really needed. And they're only needed when they have a specific purpose, one that requires participants to interact on a regular basis.

There are a number of legitimate purposes for committees. Limiting your use of committees to one of these is the key to success. Let's look at each in turn:

• Board: An internal "board of directors" to help the IT business-within-a-business succeed.

  Like any good corporate Board, they do not micromanage the CIO, but instead add value by offering input on major strategic decisions and by coaching the executive on key business and leadership issues.

  This type of committee must include people who can add value to the CIO's thinking. It may very well include outside parties such as major vendors and trusted consultants. It does not need to fairly represent all the business units.

• Purser: A committee that owns a "checkbook" of spending power, such as the portion of the IT department's budget designated for client-benefiting products and services, and makes purchase decisions by setting priorities from among the requests of the many clients they represent.

  Transfering to clients the power to set priorities within a finite checkbook keeps IT staff out of the conflicts of interests that arises when they set their own priorities, i.e., when they make clients' purchase decisions for them. It also leads to better returns on investments and "strategic alignment," since investment decisions are driven by clients' deeper understanding of their businesses and their strategies.

  A Purser committee manages a specific checkbook. It does not have the power to control other "sales," e.g., when a business unit uses its own budget to buy additional things from IT.

  A Purser committee must fairly represent either the client community as a whole, or the subset of it whom the budgeted checkbook was intended to benefit.

• Consortium: A specific set of clients who together purchase a particular product or service.

  Since they share a single contract (explicit or not) with IT, members of a Consortium must speak with one voice (as a single customer). They share decision making, costs, and ownership of the results.

  A common example of a Consortium is the set of business units which is buying ERP solutions (and follow-on services such as support and applications hosting).

• User Group: An association of people who use a given product or service.

  A User Group is distinct from a Consortium in that each member of the user group can/did purchase the product independently. They do not share a single contract with the IT organization.

  They meet to exchange information that will assist in their getting value from the product or service.

  Of course, membership is voluntary and open to all who are interested.

• Focus Group: A team of people representing potential customers who share their values, opinions, and ideas to guide the research and product-development activities of the IT organization.

  They meet at the request of the IT organization, not necessarily regularly, and answer questions provided by IT. They do not make decisions for the organization.

  Technically, a Focus Group is not a committee since it should be constituted only when needed, and just the right people should be invited based on the question at hand. It's mentioned here because some people use their IT steering committees in this way.

• Professional Community: If an IT function is decentralized, the set of executives who manage the various groups, or the set of managers of a specific sub-discipline.

  They meet to share their experiences, share research and product development, agree on standards and policies, and further the interests of the profession.

  Like a User Group, membership is voluntary and open to all who are interested.

Clarity of Purpose

It all comes down to this: Never form a committee without a crystal clear definition of its purpose -- a legitimate purpose that requires regular interactions among the same people, and one that doesn't disempower others.

It's also important not to mix purposes.

For example, a Board should be on your side, helping IT succeed. A Purser committee, on the other hand, acts as a bunch of hungry customers who want more for less. Even if many of the same executives may participate in both, it's critical that these two purposes never be combined within the same committee. This kind of conflict of interests is bound to create confusion that undermines both purposes.

And remember, a committee should never be used as a substitute for talking (perhaps one-on-one) to the people you need to work with.

Is your committee a bureaucratic albatross or a useful means to encourage interaction and gain consensus on a specific set of issues? It's all in the way you define its purpose.