Governance and Decision Rights

Steering Committees: Purpose, Membership and Agendas

What a steering committee should decide, who should sit on it, how to run agendas that stay useful, and when a smaller or lighter arrangement is enough.

On this page
  1. What a steering committee is for
  2. What it should decide
  3. Who should sit on it
  4. Building agendas that work
  5. Keeping meetings useful
  6. Common problems
  7. Right-sizing

What a steering committee is for

A steering committee is a group with authority to set direction for a shared system, service or programme. It exists because some decisions are too significant, or involve too many units, for one owner to make alone. Typically these are priorities, funding, disputes between units, and acceptance of risk.

It is not an operating team. A steering committee that reviews individual tickets or edits documents has mistaken its role. Its value lies in making a small number of decisions that others cannot, and in giving those decisions legitimacy across the organization.

What it should decide

A clear list of decisions makes the group easier to staff and run. For a shared system, a reasonable list might include:

  • the priorities for the coming period, when requests exceed capacity;
  • approval of significant changes, spending or contracts above a set threshold;
  • resolution of disagreements between units that the system owner cannot settle;
  • approval or refusal of exceptions to standards that carry significant risk;
  • acceptance of residual risks that affect more than one unit;
  • review of how well the system is serving the business.

Equally important is what it should not decide: matters within the system owner’s authority, routine operations and detailed technical design. Drawing this line is a matter of decision rights, and writing it into a short charter prevents most scope arguments.

Who should sit on it

Membership should reflect who must be present for the decisions to stick. Common seats are:

  • A senior sponsor with authority over the budget and enough standing to settle disputes. This person usually chairs or is clearly associated with the group.
  • The system owner, who brings the operational picture and carries out decisions.
  • Business unit representatives from the main user groups, preferably people with authority to commit their unit.
  • Specialist advisers such as security, finance, risk or data governance, either as members or called in for relevant items.

Some points to consider:

  1. Keep it small. Beyond roughly eight or ten people, discussion tends to become presentation. Larger user populations can feed in through an advisory group instead.
  2. Seniority matters, but so does knowledge. A group of busy executives who send deputies provides neither authority nor context. Agree whether alternates are allowed, and what they can commit to.
  3. Balance representation. One large unit should not dominate, and smaller units should have a route in. Some of the ways to achieve this are covered in the discussion of balancing central control with local input.
  4. Be explicit about terms. Membership that never changes makes a group stale; rotating some seats helps, within limits.

Building agendas that work

A few habits tend to separate useful meetings from tiresome ones.

Start with decisions. Label each item as for decision, for discussion or for information. Items for information can usually be handled in a written update before the meeting.

Circulate papers early. A short paper with the question, the options, the recommendation and the risks lets the meeting spend its time on judgment rather than explanation. A page or two is often enough.

Limit the count. Three or four substantive items is usually more than a group can treat properly in an hour or so.

Keep a standing structure. A familiar order might be actions from last time, decisions required, risks and issues, performance summary, and forward look. The performance summary should be short and based on clear metric definitions so the discussion is not spent debating what the numbers mean.

Record decisions and actions. Minutes need only list what was decided, by whom, what happens next and when. Circulate them quickly.

Keeping meetings useful

  • Ask at the end of each meeting whether anything decided could have been decided without it. If so, move it to a lighter route.
  • Track whether items are repeatedly deferred; it usually means missing information or a decision nobody wants to own.
  • Invite challenge. A committee where everything is approved without question may be receiving too little real information.
  • Follow up on actions at the next meeting; unreviewed actions teach people that decisions do not matter.

Common problems

Too much detail. Members drift into operational questions because they are easier than strategic ones. The chair can redirect these to the system owner.

No real authority. If decisions are routinely overturned elsewhere, the group is advisory, whatever it is called. Be honest about which it is.

Becoming a bottleneck. If everything waits for the next meeting, speed suffers, and the committee becomes one of the single points of failure in the way decisions are made. Delegation thresholds, with smaller matters going to the system owner, help.

Distance from users. Without regular contact with the front line, the group may decide on assumptions.

Right-sizing

A small business may not need a committee at all. A monthly conversation among the owner, the person responsible for the system and one or two department leads can fulfil the same purpose. A group with many business units may need a committee and a lower operational forum beneath it. In every case the question is whether the group makes decisions that otherwise would not be made, and whether the time of its members is well spent.

The complete guide to governance and decision rights

Governance for Centralized Systems: Roles, Forums and Decisions
Read the guide

Keep exploring

Guides from other topics

All topics →