Picture a mid-size manufacturing company that has just kicked off an ERP (enterprise resource planning) installation. Consultants are on site, the project team holds daily meetings, and things look busy. But every significant decision requires the general manager’s signature. When the general manager travels to Istanbul, the decision waits a week. A week later the committee reconvenes, a new problem surfaces, and this time the finance director is unavailable. A project planned for three months stretches to six. The software is not the problem. The committee is.
The steering committee is the top decision-making body of an ERP project. The project team handles day-to-day execution; consultants manage technical installation. But the big calls — which process gets redesigned, which module goes live first, which department transitions when — land on the committee’s table. When the committee makes those calls on time, the project moves. When it delays or avoids them, the project stops. It really is that straightforward.
Who belongs on the committee? The general manager or owner must be there without exception. The finance director, the production or operations manager, and the IT coordinator — if the company has one — round out the group. The consulting firm’s project manager attends to present information but does not vote. Keep the committee to five people or fewer. More members means more discussion, and more discussion means fewer decisions.
Meeting rhythm is the heartbeat of the project. The committee should meet every two weeks, on a fixed day and at a fixed time. ‘We will meet when needed’ does not work in practice. While the project team waits for a ruling, consultants bill hours and costs climb. A fixed calendar changes behavior immediately: team members know they have until the next Tuesday to prepare their issues properly. That discipline alone accelerates project delivery in a measurable way.
The agenda matters as much as the schedule. At least two days before each meeting, the project manager sends the agenda by fax or e-mail to every committee member. Each item is labeled clearly: is this for information only, or does a decision need to come out of it? Information items get read in advance; members ask questions during the meeting and move on. Decision items get discussed, and before the meeting ends, the decision is written down and signed off. ‘Let us think about it and talk again next time’ is not an acceptable outcome. Every deferred decision eventually costs money.
The most common failure is the committee drifting into a status-reporting audience. The project manager arrives, presents slides, explains what was accomplished last month, everyone listens politely, the meeting ends. No decision is made. That is a briefing, not a committee meeting. A steering committee does not gather to hear reports. It gathers to decide. Every agenda should include at least two items that require a concrete decision. If no decision items exist, the meeting is postponed by two weeks and the project manager is sent back to prepare properly.
Decision authority must also be defined clearly from the start. Which decisions can the project team make on its own, and which ones must come to the committee? Without that boundary, every small question escalates upward, committee time is wasted, and the project manager loses credibility. A practical rule: any decision that affects the budget or the timeline comes to the committee; technical implementation details stay with the project team. For example, which server to purchase is a technical call the team makes. But whether a department transitions to the new system in three months or six is a business call that belongs to the committee.
This article was originally written in Turkish by Gökhan MERCANOĞLU on July 15, 2002 and has been automatically translated into English and other languages using machine translation.