"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\u2019re listening." For any number of reasons, and always with the best of intentions, IT executives form \u201csteering committees\u201d comprising business and IT leaders. And more often than not, the results are disappointing. I\u2019ve 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 committees morph into obstacles that exercise power over IT\u2014authority without accountability, a classic violation of the golden rule of organizational design. In extreme cases, committees get headstrong and demand the right to micromanage IT, even to the point of getting involved in technical directions and internal decisions such as IT infrastructure. Even when they\u2019re relatively manageable, steering committees often become a bureaucratic waste of time with little added value. Sometimes, the very presence of the committee may confuse issues. The committee\u2019s concurrence may lead IT staff to think they have clients\u2019 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\u2019s meetings.... \n\nWhat Goes WrongDon\u2019t misunderstand me. I\u2019m not against all committees. It\u2019s just that most of the IT steering committees I\u2019ve 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\u2019s consider these two mistakes. \n\n\n\nCommittee Formed for the Wrong Reasons\n\n\n\nTo gain access to business executives: Believe it or not, I\u2019ve heard people offer this as a reason for their committees. Isn\u2019t it obvious that if you have something to say that\u2019s relevant to business executives, they\u2019ll grant you access to their calendars? And if you don\u2019t, you can be sure they won\u2019t show up at committee meetings. At best, you\u2019ll get their #2, or #3, or.... Access to business executives depends on their perception of your value to them. Forming a committee doesn\u2019t, in itself, make you relevant or get you that access. \n\nTo gain support for IT initiatives: If IT has an initiative that it\u2019s trying to sell the business, a rubber stamp from a committee is unlikely to hold any value whatsoever. A business executive who doesn\u2019t buy in isn\u2019t going to magically support the project because IT\u2019s committee said to. \n\n\n\nThe 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\u2019s 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. \n\nIf 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. \n\nA 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\u2019s blessing won\u2019t cover your backside. \n\nTo gain greater business involvement in IT: Involvement in what decisions? Are committees established to encourage clients and IT to meddle in each other\u2019s businesses, as if this is what a good partnership is all about? \n\n\n\nLet\u2019s get back to the basics of the business-within-a-business paradigm. Clients decide what changes they\u2019ll 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. \n\nAn 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\u2014in a mutually respectful customer-supplier relationship. I\u2019m 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. \n\nYou don\u2019t need to form a committee to work closely with specific clients on any of these legitimate interactions. But a vague purpose like \u201cinvolvement\u201d invariably leads to confusion about authorities and stress for all involved. \n\nTo communicate better with the business: Communicating regularly and well with clients is a great idea. But it\u2019s 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\u2019s no guarantee that the committee will include the people you really need to talk to about those specific issues. And there\u2019s 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). \n\n\n\nThe truth is, you don\u2019t 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\u2014when you have something to say. Keeping clients informed may not even require a meeting. According to Meyer\u2019s 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\u2019t waste people\u2019s time; just put it in an e-mail, newsletter or video. \n\nTo approve decisions made by staff: A committee of executives may be formed to \u201cbless\u201d 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\u2019t 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. \n\n\n\nIn other cases, the experts and stakeholders may not agree, and they may turn to the executive committee to break the logjam. If the committee does so, a faction of disappointed stakeholders will be expected to comply with a standard they don\u2019t 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. \n\nExecutive 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. \n\nCommittee formed with Vague PurposeThe second common mistake is to form a committee with a vague purpose, like \u201cto guide strategic IT decisions.\u201d With an unclear charter, nobody knows why they\u2019re there. These committees don\u2019t focus on the value they\u2019re supposed to deliver, because they don\u2019t know what that is. In parallel, IT staff don\u2019t know when to involve the committee. They often err on the side of safety and run everything through the committee, which of course slows everything down unnecessarily. \n\n\n\nIn addition to being a waste of time, badly chartered committees often wander into areas they don\u2019t belong in, and become bureaucratic obstacles rather than effective means of consensus. These committees disempower IT staff, slow innovation, blunt IT\u2019s entrepreneurial spirit, and make poor decisions that they\u2019re not qualified to make. Types of CommitteesIf you\u2019ve made it this far through my tirade, then I owe you a constructive view of committees. \n\n\n\nFirst, let\u2019s 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, \u201cA camel is a horse designed by committee.\u201d It speaks to a basic truth: Committees are a cumbersome way to make decisions. It\u2019s hard to manage the dynamics of a big group of people. It\u2019s hard to get consensus. It\u2019s even tough to schedule meetings and get everybody to show up! Committees aren\u2019t good in and of themselves. They should only be formed when they\u2019re really needed. And they\u2019re 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\u2019s look at each in turn: \n\n\n\nBoard: An internal \u201cboard of directors\u201d to help the IT business-within-a-business succeed. \n\n\n\nLike 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. \n\nThis type of committee must include people who can add value to the CIO\u2019s thinking. It may very well include outside parties such as major vendors and trusted consultants (or CIO.com columnists!). It does not need to fairly represent all the business units. \n\n\n\nPurser: A committee that owns a \u201ccheckbook\u201d of spending power, such as the portion of the IT department\u2019s 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. \n\n\n\nTransferring 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\u2019 purchase decisions for them. It also leads to better returns on investments and \u201cstrategic alignment,\u201d since investment decisions are driven by clients\u2019 deeper understanding of their businesses and their strategies. \n\nA purser committee manages a specific checkbook. It does not have the power to control other \u201csales,\u201d e.g., when a business unit uses its own budget to buy additional things from IT. \n\nA 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. \n\nConsortium: A specific set of clients who together purchase a particular product or service. \n\n\n\nSince 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. \n\nA 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). \n\nUser group: An association of people who use a given product or service. \n\n\n\nA 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. \n\n\n\nThey meet to exchange information that will assist in their getting value from the product or service. \n\nOf course, membership is voluntary and open to all who are interested. \n\nFocus 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. \n\n\n\nThey 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. \n\nTechnically, 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\u2019s mentioned here because some people use their IT steering committees in this way. \n\n\n\nProfessional 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. \n\n\n\nThey meet to share their experiences, share research and product development, agree on standards and policies, and further the interests of the profession. \n\nLike a user group, membership is voluntary and open to all who are interested. Clarity of PurposeIt all comes down to this: Never form a committee without a crystal clear definition of its purpose\u2014a legitimate purpose that requires regular interactions among the same people, and one that doesn\u2019t disempower others. \n\n\n\nIt\u2019s 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\u2019s 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\u2019s all in the way you define its purpose. \n\n Dean Meyer helps IT leadership teams design high-performance organizations. Author of six books, numerous monographs, columns and articles, he brings innovative systematic approaches to what others consider the \u201csoft\u201d side of leadership. Contact him at email@example.com or visit his website for information that can help you implement these ideas, or with suggestions for other buzzwords to analyze in future.