NDMA Home Page
Index of topics on this NDMA website
Search this NDMA website on Google
© 2024 N. Dean Meyer and Associates Inc.
Excerpt from www.NDMA.COM, © 2024 N. Dean Meyer and Associates Inc.

Role Analysis: Committees versus Project Teams

never form a committee to pursue a project

by N. Dean Meyer

A CIO showed me an email from one of his staff describing the formation of a sub-committee, under an existing committee, to investigate outsourcing some of their applications engineering services, choose a vendor, put in place a contract vehicle, manage spending, and measure compliance. He was asked to approve the membership list.

"What do you think of this?" he asked me.

"Hmm, 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?"

"I sure did!"

"And that includes the smart use of vendors, right?" I queried.

"Absolutely!"

"And who's supposed to police that?" I asked.

"Their bosses, of course," was his logical reply. "If a manager isn't offering our customers a good value, we have a performance issue."

"And don't you already have an IT procurement group who's job is to research sourcing alternatives, and help the managers form relationships and buy stuff?" I continued.

"We do," he replied.

"So what's this committee supposed to do?" was my obvious question.

How Things Should Work

Sometimes people form committees when they want help from peers, even if a project team would do just as well -- one that will go away when the job is done, unlike committees which take on a life of their own.

Let's get back to basics. In a healthy organization, every manager is an empowered entrepreneur with a business to run. "Empowered" means that authorities and accountabilities match. Each manager has just enough authorities to fulfill his or her accountabilities -- no more, no less.

Managers may sell their products and services to clients (outside their departments), 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 an example within IT, a manager responsible for an applications development project may buy help from other groups 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, and procurement services.

Every manager must be 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 (quality and functionality divided by 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, then the procurement function may help them select a shared 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.

Never Form a Committee for in Lieue of a Project Team

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

Final Decision on the Outsourcing Committee

In the case of the proposed outsourcing committee, the CIO decided that it is appropriate. But its purpose was 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 committee have no power to enforce their decisions (for example, to force people to make use of the committee's chosen outsourcing vendor).

In announcing his decision, he 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 draw on the vendor contract (or not). But the committee would not enforce use of vendors, or get involved in individual managers' decisions about the impact of such a vendor contract on their budgets.

What really sent a strong signal to the organization was that his reply was phrased as a policy, 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 help on a project, form a project team, not a committee!

Abstracts

Free library

Books

Speech abstracts

NDMA coaching/consulting services

UP....

NEXT PAGE....