Running Better ERP Steering Meetings. Bring clear options and leave with agreed actions.
Imagine an ERP steering meeting that ends with a sensible-sounding conclusion: “Proceed, provided the risks are managed.” The sponsor believes the team has permission to continue. The test lead thinks the decision is conditional on another rehearsal. Finance expects a revised cost estimate. Nobody can tell the implementation team which instruction takes effect tomorrow.
The meeting produced agreement in the room, but the operating decision remains incomplete. A usable decision states the choice, its boundaries, any conditions, who will act, and how completion will be verified.
Steering committees can design their meetings around that output. The approach below uses a one-page decision packet, a focused agenda, and a decision-to-action ledger. Adapt it to your formal authority and committee requirements. Its purpose is to make executive judgment available to the people doing the work.
Classify the agenda before building the slides
Separate information, advice, and decision items. Each serves a different purpose and needs a different outcome.
An information item keeps members aware of a verified change or emerging concern. An advice item asks for perspective before a responsible owner decides. A decision item asks the committee to exercise authority it actually holds. Labeling them prevents an exploratory conversation from being mistaken for an approval.
Move routine progress information into a concise pre-read where practical. Preserve meeting time for material changes, disputed trade-offs, and choices that cannot be made within delegated authority. A committee should still challenge the information behind a recommendation; a pre-read is no excuse to conceal uncertainty.
Before adding a decision item, the meeting coordinator should verify four things: the question is answerable, the committee has the relevant authority, the required contributors have been consulted, and the choice has a meaningful deadline. An item that fails this check may need preparation or a different decision route rather than a longer meeting.
Write the decision request in one sentence
Start the packet with the sentence the minutes should be able to record. For example: “Approve or reject the proposed sequencing change that moves the second warehouse rollout until after the first location's acceptance criteria are met.”
That question is clearer than “Warehouse rollout update.” It tells members which choice is theirs and makes the affected boundary visible. The packet can then explain the options without asking readers to infer what decision is needed.
State the latest useful decision date and the consequence of waiting. If the committee can reasonably defer the choice, describe what additional evidence will become available and what work can safely continue. If delay closes an option or causes rework, identify that dependency specifically.
Do not present urgency as a reason to bypass an approval obligation. An urgent request with missing evidence may call for a limited interim authorization, a stop, or an explicit acceptance of a defined exposure by the appropriate authority. These are decisions too.
Build a packet that exposes the trade-off
A one-page packet is a discipline for clarity, not a limit on evidence. Attach or link detailed material so members can inspect the analysis. Keep the core page readable enough to compare the choices.
Use the following structure:
- Question and authority: what must be decided, and why this committee owns it.
- Deadline and dependency: when the answer is needed and what waits for it.
- Options: materially different courses of action, including a credible deferral where relevant.
- Evidence: verified facts, assumptions, source owners, and important gaps.
- Trade-offs: effects on scope, timing, cost, controls, people, and service.
- Recommendation: the proposed choice and the reasoning behind it.
- Downside: the strongest case against the recommendation and how it would be managed.
- Execution: action owners, conditions, verification, and reconsideration triggers.
Avoid inventing weak alternatives to make the recommendation look inevitable. If only one option is currently feasible, explain why the others were excluded and what evidence supports that conclusion. Members can then challenge the constraints rather than compare artificial choices.
Keep evidence and judgment visibly separate
Executives should be able to identify what the team knows, what it estimates, and what it prefers. “The second rehearsal has not completed” is an observable fact. “The remaining issues can be resolved before launch” is a forecast. “We recommend protecting the current launch date” is a judgment.
These statements can all belong in a packet, but they should not be blended into a single green status label. Give important forecasts a basis, an owner, and the uncertainty that could change the answer.
In a hypothetical rollout decision, the first location may have passed its operational scenarios while the second has unresolved receiving exceptions. The committee needs to understand whether the shared support team can handle both locations, whether delay preserves an option, and what evidence would authorize the second release. A count of completed tasks alone cannot answer those questions.
Where a decision involves accounting, legal, security, or regulatory obligations, identify the accountable specialist review. A committee's business preference does not substitute for a required determination in those areas.
Bring dissent into the packet
A recommendation that conceals unresolved disagreement gives the committee an incomplete picture. Include the strongest material objection and the evidence behind it. Name the role raising it, describe the consequence they are protecting against, and explain where the analysis agrees or differs.
This is especially important when one function receives the benefit while another inherits the workload or control exposure. A rollout sequence may simplify delivery while creating a difficult support arrangement. A scope reduction may protect timing while adding recurring manual work. The operating owner should be heard before the choice is finalized.
Do not turn dissent into a requirement for universal agreement. The committee's job may be to decide between legitimate competing priorities. The packet should make that trade-off explicit enough for the authorized members to own it.
If the disagreement is factual, resolve it where possible before the meeting. If it concerns tolerance for a known downside, label it as a judgment question. That distinction helps members spend time on the issue they can actually settle.
Run the meeting around decisions
A practical agenda begins by confirming what changed since the pre-read. The presenter then states the decision request, the recommendation, and the most consequential uncertainty. Members ask questions about the evidence and trade-offs before the chair tests the proposed resolution.
Reserve time to read the final decision back. This brief step can reveal that different people heard different conditions. Capture the result while everyone who holds the authority is still present.
For each decision, ask:
- What exactly has been authorized, rejected, or deferred?
- Which conditions must be met, and who can confirm them?
- Who carries out the next action, and by when?
- What may proceed now, and what must wait?
- What evidence or event would bring this choice back?
Where members lack the information to decide, record a deliberate deferral. Assign the missing evidence, its owner, and the next decision point. “More analysis needed” is incomplete unless somebody can tell what analysis would change the choice.
Translate the resolution into an action ledger
Meeting minutes preserve the record. A decision-to-action ledger makes the record executable. Link the two so implementation teams can see the authorized wording and their own obligations.
A useful ledger entry includes a decision ID, the exact resolution, conditions, action owners, due dates, dependent work, verification evidence, and current status. If the decision authorizes several actions, give each its own owner and completion evidence. Avoid assigning an action to “the program” or “the business.”
For the hypothetical warehouse sequence, one action may revise the integrated plan, another may update training dates, and a third may confirm support coverage. The decision is not fully implemented merely because the plan changed. The ledger should expose those separate commitments.
Define who checks completion. For a routine schedule update, the program coordinator may verify the evidence. For a control condition, the appropriate control owner should do so. Closing an action requires the agreed result, not only the action owner's statement that work was performed.
Inspect whether decisions reached the work
At the next meeting, review material unfinished actions and decisions whose assumptions changed. Avoid rereading every closed item. Instead, sample whether the people affected can find the answer and whether it appears consistently in plans, designs, tests, and operating instructions.
A recurring pattern of reopened decisions deserves attention. It may indicate unclear authority, weak evidence, missing stakeholders, or resolutions that leave too much to interpretation. More frequent meetings will not automatically solve those problems.
Start with one forthcoming decision. Replace its status deck with a clear packet, then record the resolution in language an absent workstream lead can follow. If that person can explain what they are allowed to do, what they must verify, and when to return for guidance, the committee has produced something useful.
