"We want to build better partnerships."

"We want to keep people informed."

"We want to get people to support our decisions."

"We want to build 'ownership' of our projects."

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

For any number of reasons, and always with the best of intentions, people form committees -- lots of committees. Many organizations are overrun with committees, despite that fact that managers universally complain that they spend too much time in meetings. And their legitimate concerns about committees are numerous....

Concerns about Committees

Some concerns about committees 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. And as a result, the committee becomes relatively useless.

Some are costly. Committees often become a bureaucratic waste of time with little added value. To get anything done, you have to get past many hurdles, and everybody has to agree on everything. That slows organizations down (the opposite of agility), blunts staff's entrepreneurial spirit, and creates obstacles to innovation.

Sometimes, the very presence of a committee confuses issues. For example, the committee's concurrence may lead internal service providers to think they have clients' support, when the real decision-makers (which may or may not be the top executives) have not yet agreed.

Or worse, people may form committees when they want to duck personal accountability. A decision may be theirs to make. But out of fear of accountability for the results of that decision, they form a committee to make the decision for them.

Other complaints are far more serious. Let's use IT as an example.... Too often, instead of helping IT achieve its objectives, steering committees actually try to steer IT. In extreme cases, steering committees get headstrong and demand the right to oversee hiring decisions, technical directions, and internal decisions such as IT infrastructure strategies.

They morph into micro-managers that exercise power over IT -- authority without accountability, a classic violation of the Golden Rule of organizational design. And in the process, they disempower managers who are accountable for results and hence should have the authorities to make decisions on their own.

For example, an IT outsourcing committee could attempt to force managers to buy from its chosen vendor, whether or not doing so is in those managers' best interests. Or it might attempt to deny managers the right to buy from alternative vendors, even when (in a particular manager's unique line of business) another vendor is the right choice. If it does either of these things, then managers will be disempowered, and can no longer be held accountable for the costs or quality of their individual businesses within the business.

Even when they're relatively manageable, more often than not, the results of committees are disappointing. 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! Many committees fail to deliver intended benefits, or do more harm than good.

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

What Goes Wrong

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.

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

Before looking at the right use of committees, let's consider these two mistakes.

1. Vague Purpose

The second common mistake is to form a committee with a vague purpose, like "to guide strategic 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, 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 the internal service provider, slow innovation, blunt staff's entrepreneurial spirit, and make poor decisions that they're not qualified to make.

2. Wrong Purpose

Here are some examples of the wrong reasons 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 greater business involvement in your function:

Involvement in what decisions? Are committees established to encourage clients and internal service providers 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 internal service providers like IT. Internal service providers decide what projects to bid, what alternatives to offer, and how to go about delivering their products and services.

An effective partnership is not a result of each meddling and disempowering the other. Great partnerships occur when internal service providers offer 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. Internal service providers can be very proactive by helping clients discover strategic opportunities for their products/services, by offering 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" generally leads to confusion about authorities and stress for all involved.

To communicate better with the business:

One oft-cited reason for committees is to provide a forum to keep leaders informed.

Communicating regularly and well with clients is a great idea. But, of course, you don't need committees (or even meetings) to disseminate information. 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. It's far more efficient to simply send information out to affected parties whenever appropriate.

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 gain support for your initiatives:

If an internal support function (such as IT) has an initiative that it's trying to sell the business, a rubber stamp from a committee is unlikely to hold any real value. 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 business-benefitting 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.) Internal support functions should never be in the position of trying to sell client-benefitting projects to the business.

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 a cloud vendor 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 your initiatives. And if you fail to sell the right people, the committee's blessing won't cover your backside.

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. 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. This embodies the essence of "bureaucracy" -- time-consuming efforts with little added value.

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.

To build collaboration on projects:

If the objective is a one-time deliverable (a project), there's no need for a committee. The risks of vague accountabilities is too great.

Instead, assign accountability to one group -- the one that's in the business of delivering the intended result.

If that group needs help from others, form a project team. And assign clear accountabilities for deliverables to each participating member of the team. That's the basis for high-performance teamwork.

Fundamental Principles

The Market Organization explains how to avoid unnecessary obstacles and bureaucracy which are costly and reduce your agility.

The Market Organization is based on two pillars:

• Business-within-a-business paradigm: Every group on the organization chart is defined as a business, there to serve customer inside and outside the organization.

• The Golden Rule of empowerment: Authorities and accountabilities must match.

These two pillars are the key to defining the appropriate uses of committees.

Types of Committees

The effectiveness of a committee starts with a clear definition of its purpose. So, what are legitimate purposes for committees?

In a Market Organization, there are a limited number of appropriate purposes for committees. (Some are only relevant to internal service providers, marked "[Internal]".)

• Advisory Board: An internal "board of directors" that helps a business within a business succeed, with advice at the strategic (not operational) level.

• Stakeholders: A set of people who are impacted by a class of decisions, and hence share authority over those decisions.

• Purser: A committee that owns a "checkbook," represents internal customers, and decides priorities for an internal service provider.

• Consortium: A specific set of internal customers who together purchase and share a specific product or service.

• User Group: An association of people who share with one another their experiences using a specific product or service.

• Focus Group: People representing (internal) customers who share with the organization their values, opinions, decisions, and ideas.

• Professional Community: If a function is decentralized, the members of a common profession (regardless of where in the enterprise they report) who share experiences and advance the profession.

Limiting your use of committees to one of these is the key to success. Let's look at each in turn:

Committee Type: Advisory Board [Internal]

An internal "board of directors" helps a business within a business succeed.

Like any good corporate Board, they do not micro-manage the executive or engage in discussions of operational issues. Instead, they add value by coaching the executive on key strategic and leadership issues.

Unlike a corporate Board, this type of committee must not usurp the authority of the organization's supervisor (one up from the organization's executive). In an empowered organization, bosses (and no one else) have the job of managing subordinate leaders. Nobody needs two bosses! This type of committee has no "oversight" authorities over the organization it serves.

Similarly, an Advisory Board has no decision authorities.

An internal Advisory Board should include anyone who can add value to the executive's thinking. It may include outside parties such as major customers, vendors, and trusted consultants. It does not need to represent all the internal service provider's customers.

Again unlike a corporate Board, it's there to serve (not manage) the executive. So, its composition and agenda should be controlled by the executive.

Committee Type: Stakeholders

The set of people who are impacted by a class of decisions, and hence share authority over those decisions (per the Golden Rule).

For example, a policy or standard may impinge on many people's work. That policy should be designed by the stakeholders; or at a minimum, they should have the authority to approve any such a policy. This ensures that one group cannot unilaterally issue edicts that constrain others' ability to do their jobs.

"We had a committee that decided policies, and variances from policies, in product pricing. We didn't want one product manager tipping the market and forcing price reductions in other product lines."

Sergio Paiz, CEO, PDC

Another example of shared interests is where decisions about one product impact other products in a brand. Examples include product designs (where a "family resemblance" helps build the brand), pricing, marketing strategy, and advertising messages. In these situations, a product manager should be required to gain the consensus of all affected product managers before making such decisions.

In operational functions, another example is "change control." Before anything new is introduced into a production environment, all those who could potentially be harmed by the change should share the authority to approve it.

When an organization sells a system of interconnected solutions (as does IT), another example is interoperability. One business unit may wish to buy a solution (or make a change to an existing solution) that will harm others -- in IT, for example, by fragmenting data or business processes, precluding others' access to needed information, costing others more (e.g., the increased costs of integrations due to variances from standards), or actually causing other systems to fail (the "ripple" effect). Those other affected business units should have a say in that decision.

In each of these examples, one person's decision can have unintended consequences for others. Where such interdependencies are recurring, a Stakeholder committee represents those who might be affected; it gives them authorities over a specific class of decisions to protect themselves.

Stakeholder committees may not need to meet regularly. They may be convened on an as-needed basis.

When the selection of people varies based on the specific decision being discussed, a committee should not be formed. Instead, a Coordinator should be identified who brings together the right people as needed. Product design standards are an example of this, since the list of stakeholders varies based on the standard being discussed.

Committee Type: Purser [Internal]

In a Market Organization, an internal support function's budget is treated as prepaid revenues -- a "checkbook" to buy the department's products and services in the year ahead.

A Purser committee owns all or part of that checkbook, and decides what checks to write. In other words, it sets priorities among the many competing requests coming from the clients it represents, and decides what to "buy" from the organization within the bounds of its checkbook.

Transfering to clients the power to set priorities within a finite checkbook keeps support staff out of the conflicts of interests that arise 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's only job is to manage 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 the internal service provider.

Any committees which do not own a checkbook may advise the Purser, and may filter requests before they're submitted to the Purser for approval, i.e., they can say no to projects. But lacking a checkbook, these other committees cannot approve projects (they cannot say yes). They are Stakeholders, not Pursers.

A Purser committee should fairly represent the people who benefit from its checkbook. The highest-level Purser should represent the enterprise as a whole -- all the business units. If they divide the checkbook into sub-checkbooks, each checkbook needs its own Purser committee representing specific subsets of the client community.

The internal service provider itself should not be a voting member because, in the spirit of building great relations with its customers, it should not judge customers' requests or become an obstacle to them.

Committee Type: Consortium [Internal]

Sometimes, multiple business units share an asset or service by forming a Consortium that acts as a single customer to an internal service provider. (In IT, for example, a number of business units share ownership of the ERP system.)

Since the members of a Consortium share a single thing (an asset or a service), they must speak with one voice as a single customer. They share decision making, costs, and ownership of the results.

A Consortium is distinct from the market as a whole. "Off-the-shelf" products and services are made available to any and all who wish to buy them. They're not customized to satisfy requirements defined by specific customers or Consortia. Instead, they're designed to satisfy the bulk of the market as a whole. The market as a whole is not a Consortium; each customer buys independently.

Again using IT as a familiar example, the entire company buys the email service; but they don't all have to agree on what they buy. IT decides what to offer (hopefully with input from customers); then, customers independently subscribe to the service. This is not a Consortium situation.

On the other hand, an ERP system is a single asset owned by multiple business unit who form a Consortium to buy, own, manage, and use it.

A Consortium is a customer to an internal service provider. That supplier is not a member of the Consortium committee (although it may facilitate it).

A separate Consortium committee is formed for each unique asset, since each might benefit a unique set of clients.

Committee Type: User Group

User Groups comprise people who use specific products or services.

A User Group is distinct from a Consortium in that each member of the user group can (or, more likely, did) purchase the products or services independently. They do not share a single contract with the supplier organization (as does a Consortium).

User Groups meet to exchange information that will help them get value from the organization's products or services. Membership is voluntary and open to all who are interested.

The internal supplier organization is not a member of its User Group; it just facilitates it (a marketing service).

User Groups have no authority over the supplier.

User Groups may also serve as Focus Groups (below), giving the organization feedback.

Committee Type: Focus Group

A Focus Group (a.k.a., advisory panel) represents an internal service provider's market (current and potential customers), and shares with the organization its values, opinions, decisions, and ideas, for example, to guide research and product-development activities.

Focus Groups meet at the request of the internal service provider, not necessarily regularly, and answer questions provided by the organization. They do not make decisions, and have no authority over 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 questions at hand. It's mentioned here because some organizations use committees in this way.

Facilitation of Focus Groups is a market research service.

Committee Type: Professional Community

A Professional Community includes the members of a common profession, regardless of where in the enterprise they report.

If a function is decentralized, connecting the members of a Professional Community is particularly valuable since their opportunities for collaboration may otherwise be limited. This is a weak patch for one of the many costs of decentralization.

They meet regularly to exchange their experiences, share research findings, agree on standards and policies, and further the interests of their profession.

Membership is voluntary and open to all who are interested.

A Policy on Committees

A policy can provide guidelines on when to form committees, and how to charter them.

Based on this simple observation, consider the following policy regarding committees:

1. Committees shall only be formed when there is an ongoing need for two-way collaboration (beyond the scope of specific projects).

In general, meetings should only be used for communications, such as sharing and discussing information, or collaborating on shared decisions.

And regularly scheduled meetings (as with committees) should only be used for two-way exchanges that must happen regularly -- when there's a need for participants to interact on a regular basis.

There are two types of collaboration that warrant committees:

- Sharing information among people whose normal job functions create shared interests, such as professional exchange.

- Making shared decisions by people whose normal job functions give them a voice in an ongoing series of decisions.

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.

2. Every committee shall have a written charter that defines its purpose and its membership.

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. There should be no "steering committees" with vague charters that let them meddle in leaders' operational decisions.

That purpose shall be clearly documented in a charter, along with criteria for membership.. Membership shall be defined by job functions, not the names of individuals (for example, "members include anybody whose job is...."), and shall be open to anybody who meets those requirements.

No committee shall have multiple purposes, since that can create conflicts of interests.

For example, a Board should be on your side, helping you succeed. A Purser committee, on the other hand, acts as a set 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.

When the same executives participate in multiple committees, it's all the more critical to precisely define the purpose of each. Even if the same people are on both committees, the committees' purposes (and meeting agendas) should never be mixed.

3. No committee shall exist to perform a product/service delivery function.

When it comes to accountabilities for results, committees make a poor substitute for a specific group accountable for a deliverable. When everyone is accountable, no one is accountable. And shared accountabilities often lead to finger-pointing.

Meanwhile, a committee made responsible for deliverables would relieve the appropriate individuals of their accountabilities.

Responsibility for every product or service should be exclusively within the domain of a group in the organization, not in a committee.

4. Committees shall not substitute for project teams.

When the objective is an identified outcome or deliverable, no committee shall be formed. Instead, a project team shall be formed and disbanded when the project is complete.

5. No committee shall be given any authority.

The Golden Rule of organizational design applies to committees: authorities and accountabilities must match.

Vesting any authorities in a committee (other than the sum of its members' authorities) inevitably disempowers those who are accountable for results. Committees should never make decisions that are within the authorities of individual leaders.

The power of a committee comes from the authorities of its members, which is is granted within their normal job functions. Members of a committee may pool their respective authorities over shared decisions. And they agree to use their respective authorities to implement shared decisions.

As such, no committees with unique authorities of their own are required. Therefore, no committee will disempower anybody.

Committees provide a forum that may help people agree, but do not make decisions for anybody but their members, and they do not enforce compliance with their decisions. All authority shall be exercised through the normal chain of command.

6. Committees shall not oversee others.

Closely related to Rule #5, committees should not have "oversight" responsibilities. If a committee has oversight authority over a group, it disempowers that group's supervisor.

Controls should be exercised via the legitimate authority of the management reporting hierarchy, not via a committee of peers usurping the authorities of a boss or acting as a second boss.

Conclusion

There's no need to saddle yourself with bureaucracy in the form of unnecessary or poorly chartered committees.

As long as you are deliberate about their purpose, charter them properly, and include the right people in each, committees can be a useful catalyst of collaboration.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....