Use Committees Constructively and Bust Bureaucracy

A CIO showed me an e-mail from one of his staff describing the formation of a new committee to investigate outsourcing some of their applications engineering services, choose a vendor, let a contract, manage spending, and measure compliance. He was asked to approve the membership list.

RELATED LINKS

Set IT Policies the Right Way

Advice for Managing Business Meetings

“What do you think of this?” he asked me.

“It doesn’t feel right,” I replied. “Didn’t you make it clear that every manager’s job includes continually seeking ways to save money? And that includes the smart use of vendors?”

“I sure did!”

“And who’s supposed to police that?” I asked.

“Their bosses, of course,” was his logical reply.

“And don’t you already have an IT procurement group to research sourcing alternatives, help the managers form relationships and buy stuff?” I continued.

“We do,” he replied.

“So why do you need this committee?”

He didn’t have an answer, and that’s when I began to wonder if people form committees whenever they want help from peers, even if a project team—which would go away when the job is done—would do just as well. Committees generally take on a life of their own.

More cynically, I wondered if people form committees when they want to duck personal accountability, or perhaps just when they get lonely in their cubicles or offices.

Committees have a useful purpose. But too often, they’re bureaucratic, disempowering, or, at a minimum, a source of ambiguous accountabilities and confusion. This column explores what can go wrong and defines the proper role of committees.

What’s Wrong With Committees

Many organizations are overrun with committees, in spite of managers universally complaining that they spend too much time in meetings. Committees are expensive and are often not very productive. They may slow decision making, or just waste a lot of people’s time.

Indeed, in some cases, committees are destructive. They confuse individual accountabilities and may disempower managers who should have the authority to make decisions on their own.

For example, this outsourcing committee, with its broad mandate, 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 other vendors, even when (in a particular manager’s unique line of business) an alternative vendor is the right choice.

If that is how the committee operates, then managers will become disempowered and can no longer be held accountable for the costs or quality of their individual businesses within the business.

Then again, if it looks like the committee is going to get in people’s way, then those people (who, don’t forget, are also members of the committee) will make sure that the committee never gets anything done! At best, the committee becomes a waste of time; and at worst, it undermines the healthy functioning of the organization.

How Organizations Should Work

If you go back to basics, you’ll see why you shouldn’t need lots of committees. In a healthy organization, every manager is an empowered entrepreneur with a business to run. Empowered means that authority and accountability match. Each manager has just enough authority to fulfill his or her accountabilities—no more, no less.

Managers may sell their products and services to clients (outside IT) or to one another. Looking at it the other way, managers may “buy” help from one another (whether or not money changes hands). This is the basis for high-performance teamwork.

For example, a manager responsible for an applications development project may buy help from other groups within IT that sell data modeling, platform engineering, testing and installation into production.

Outside the context of a specific project, managers may buy help from peers such as the IT business office, which may offer HR, finance, asset management, facilities, administrative services and procurement services.

In my CIO friend’s organization, every manager is held accountable for both cost and the reliable delivery of quality products and services. As such, every manager has an incentive to use outsourcing vendors whenever doing so can improve their value proposition (defined as the quality and functionality of products and services divided by their cost). Every manager may use the services of the procurement function to find the right vendor and negotiate a contract.

If a number of managers are interested in outsourcing, the procurement function may help them select a shared vendor. Then the procurement function can help them select a vendor and put a contract in place.

The procurement function also can manage the vendor relationship, providing a single point of contact for that vendor and facilitating communications (but not determining what the various managers will buy).

Of course, it’s up to each empowered manager to decide when to draw on that shared contract, including supplying all technical requirements, getting the budget to pay the vendor and accepting accountability for results. He or she doesn’t need a committee to make those decisions.

A Policy on Committees

Since all the right things can happen without a committee—and should happen in the normal course of doing business—what’s the purpose of a committee?

Committees provide a forum for ongoing collaboration.

It’s just that simple. Don’t form a committee for any other purpose.

Based on this observation, my CIO friend and I crafted the following policy regarding committees:

1. No committee shall exist to perform a product or service delivery function that should be within the domain of a group in the IT organization or elsewhere in the corporation.

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

3. Committees shall be formed only when there is an ongoing need for collaboration (beyond the scope of specific projects), and only for the purposes of:

• 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.

4. All committees shall have a written charter that defines their purpose and their membership. Membership shall be defined by criteria related to 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.

5. No committee shall be given any authority. The power of a committee comes from the authority of its members, which is inherent in their normal job functions. Members join voluntarily and agree to use their respective authorities to implement shared decisions. As such, no “executive sponsors” are required.

6. No committee shall disempower anybody. Committees provide a forum that may help people agree, but they 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.

What Happened to the Outsourcing Committee

In the case of the proposed outsourcing committee, the CIO decided that it is appropriate because he saw an ongoing need for collaboration. But its purpose is limited to defining shared requirements for vendor contracts and exchanging professional information relevant to making good use of such contracts. He made it clear that the committee had no power to enforce any of its decisions, for example, to force people to make use of the outsourcing vendor the committee eventually chooses).

In announcing his decision, the CIO reminded everyone that all IT staff are responsible for continually improving their value and reducing costs. As such, all are accountable (to their supervisor and their customers) for making appropriate use of vendors.

Thus, individual managers are free to join the committee, or not, and to use the vendor contract, or not. But the committee would not enforce use of any vendors or get involved in an individual member’s decisions about his or her budgets.

What really sent a strong signal to the IT organization was that the CIO’s reply was phrased as a policy—not a decision on just this one committee—and that he requested examination of the miasma of existing committees in light of this new policy.

So, at least in this organization, if you want to duck accountability or you’re feeling lonely in your cubicle, take a day off —but don’t form a committee! How’s it done in your organization?

You can read another version of this column on consultantN. Dean Meyer’s website with links to other Beneath the Buzz columns, relevant white papers, books, and other resources. Contact him at dean@ndma.com