What a Steering Committee Actually Is, and Why You Are Using It Wrong
There is a certain kind of project manager: experienced, well-intentioned, technically capable, who prepares for a steering committee meeting the way a student prepares for a viva examination.
She rehearses answers. She anticipates questions. She stress-tests her narrative against every possible challenge and prepares a rebuttal for each one. She arrives in the room composed, articulate, and comprehensively ready to defend her position.
She has misunderstood the room entirely.
A steering committee meeting is not a viva. The committee members are not examiners. Their job is not to evaluate whether the PM has performed adequately and assign a grade. Their job is to govern, which is an entirely different activity, requiring entirely different inputs, producing entirely different outputs.
The PM who arrives to perform has brought the wrong thing.
The Fundamental Misunderstanding
Let us be precise about what a steering committee is: not the formal description that appears in the project charter, but the functional reality of what it exists to do.
A steering committee is a concentration of authority assembled in one room at regular intervals for one purpose: to exercise the power that the delivery team does not have.
Read that again, because it is the sentence that most PM training glosses over.
The steering committee is not there to be informed. Information is a means to an end, not the end itself. The committee is there to act: to make decisions, unlock resources, remove blockages, escalate to the board, call vendors directly, renegotiate with clients, reassign budget, and do the dozen other things that a project manager, however capable, simply does not have the organisational authority to do unilaterally.
Every person in that room has been placed there because of what they can do, not because of what they know. The CFO can release contingency budget without a six-week approval process. The Chief Operating Officer can reprioritise plant resources in a conversation. The VP of Projects can call the vendor’s regional director and get a commitment that the PM’s emails have been unable to extract for three months. The independent board member can ask questions of the client that the delivery team cannot ask without damaging the commercial relationship.
This is not a theoretical capability. It is a practical, time-sensitive, perishable resource. Perishable because the CFO’s ability to release contingency is most valuable at month six, when the overrun is 8% and recoverable. At month fourteen, when the overrun is 31% and the project is too far advanced to restructure, the same authority produces only damage control.
Time-sensitive because the VP of Projects’ call to the vendor is most effective when the interface issue has been open for two weeks, not fourteen. After fourteen weeks, the vendor has built workarounds, assigned other resources, and adjusted its own plan. The escalation still happens, but its leverage is a fraction of what it would have been.
It is a resource, because authority, like every resource, can only be deployed against problems that have been disclosed. A steering committee that does not know a problem exists cannot direct its authority toward solving it.
The PM who manages her dashboard to avoid uncomfortable committee conversations is not protecting herself from scrutiny. She is disarming the most powerful resource available to her project, and doing so with her own hands, at the moment when the resource would have been most effective.
Haath mein talwar hai, aur hum chaadar odh ke so rahe hain. The sword is in our hands and we are sleeping under a blanket.
The Performance Trap: Why PMs Treat Committees as Audiences
Understanding why this misunderstanding is so persistent requires understanding the environment that produces it.
Project managers in large organisations are evaluated, formally and informally, on the smoothness of their stakeholder management. The PM who runs a steering meeting without drama, who answers every question fluently, who leaves the room with the committee’s confidence intact, is seen as a skilled communicator and an effective leader.
The PM who surfaces a Red item, triggers a forty-five minute committee discussion, requires a resource decision that inconveniences two committee members, and leaves the room with three action items assigned to senior leadership: that PM is sometimes seen as someone who “doesn’t manage her escalations well.” Or even worse, “has no basic attitude to maintain rapport” (goody-goody behaviour implied)
This evaluation is exactly backwards. The second PM is using the governance structure correctly. The first PM is performing for it. But because the feedback loop rewards smooth performances and penalises productive discomfort, project managers learn, rationally, in response to real incentives, to optimise for the committee’s mood rather than the project’s needs.
Over time, this optimisation becomes habit. Habit becomes culture. Culture becomes the unspoken norm of every programme in the organisation: keep the committee comfortable, manage the bad news internally, arrive with solutions not problems.
And the committee, fed a diet of curated presentations and managed dashboards, gradually loses its ability to govern, because governing requires accurate information about what needs to be governed, and accurate information has been systematically withheld in the name of professional polish.
Angrezi mein bolein toh: The committee has been beautifully managed into complete uselessness.
The Three Things a Steering Committee Can Do That a PM Cannot
To make this concrete, it helps to enumerate specifically what a steering committee possesses that a project manager does not, and what is therefore lost when the committee is treated as an audience rather than an intervention mechanism.
Authority That Bypasses Normal Channels
A project manager requesting additional budget goes through a defined process: business case, finance review, approval chain, timeline. In most large organisations, this process takes six to ten weeks if it goes smoothly. If it hits a challenge at any stage, it takes longer.
A CFO on a steering committee can make the same decision in a fifteen-minute conversation during a steering review and can instruct her finance team to process it the same afternoon. This is not a circumvention of governance. It is governance, operating at the level it was designed to operate at.
The difference between these two paths is not just time. It is often the difference between a recoverable situation and an unrecoverable one. A project that needs a 12% budget uplift at month six, received within two weeks, can replan and recover. The same project, if the uplift takes ten weeks to process through normal channels, may reach month nine before the resource arrives, by which point the schedule impact has compounded to a point where the budget uplift alone cannot solve the problem.
Relationships That the Delivery Team Cannot Access
In every large ERP or MES implementation, there comes a moment when the project’s commercial relationship with a vendor becomes adversarial. Deliverables are missed. Fingers are pointed. The vendor’s account manager says things are “being addressed at the technical level” while the technical level says it is “waiting on vendor clarification.” Emails are written. Responses are slow. The bilateral escalation path has been exhausted.
At this moment, what the project team needs is not another email. It is a phone call from someone whose name the vendor’s regional leadership recognises: someone who can say, in a short conversation, that the current situation is unacceptable and that the consequences of continued non-delivery have now escalated to a level that the vendor should take seriously.
A steering committee member with an existing relationship with the vendor’s senior leadership can make that call. The project manager cannot, because she does not have that relationship, and because even if she did, the call from a PM carries a different weight than the call from a client organisation’s VP.
This is not about seniority for its own sake. It is about the specific leverage that comes from the commercial relationship existing at the right organisational level, and the fact that leverage depreciates rapidly if it is not deployed while the vendor still has time to course-correct.
The Ability to Make Cross-Portfolio Decisions
In any large organisation running multiple programmes simultaneously, resources are shared. The same subject matter experts, the same technical infrastructure, the same business process owners are being requested by multiple project teams at the same time.
A project manager who needs a specific resource that has been assigned to another programme cannot unilaterally redirect it. She can request it, negotiate for it, make the case for her priority. But the decision to take a resource from one programme and give it to another is a portfolio-level decision that requires someone with visibility of both programmes and authority over both.
That person is in the steering committee room. Often, they are the committee chair.
A PM who is short a critical resource has, sitting in the same room as her every fortnight, the person who can solve that problem in a single conversation, provided she tells that person what the problem is, what she needs, and why the decision needs to be made now rather than deferred.
If she reports Green instead, that person leaves the room without knowing the problem exists, and the project continues to be short the critical resource for another two weeks, at the cost of two more weeks of schedule pressure.
Committee mein tha jawab, aur humne sawaal hi nahi kiya. The answer was in the committee room and we never asked the question.
What the Perishable Resource Looks Like in Practice
The ERP Example: The Budget That Was Almost Available
An integrated steel plant is eighteen months into a full ERP rollout: finance, procurement, maintenance, and production planning in scope. In month nine, the project manager identifies that the data migration effort has been significantly underestimated. The legacy system has thirty-one years of production data, much of it in formats that require manual transformation. The migration team needs six additional weeks and four additional specialist resources to complete the work within the programme’s go-live window.
The cost of the four additional resources for six weeks is, in the context of the overall programme budget, modest: less than 4% of the total project cost.
The PM assesses the situation. She believes she can manage the data migration internally by reducing the scope of historical data migration, bringing across five years of data instead of ten, and archiving the rest. She reports Green. She does not escalate.
Over the next six weeks, she implements the reduced scope approach. What she does not know, because she has not had the conversation, is that the finance controller who sits on the steering committee had specifically requested ten years of historical data for the tax audit trail and had communicated this to the project sponsor at the beginning of the programme. Five years is not acceptable for the audit requirement. This was documented in the original scope definition, which the PM read but did not cross-reference against the data migration scope reduction she was implementing.
The reduced scope migration completes. The project reports Green at month fifteen. In month seventeen, two months after go-live, the external tax auditors request transaction records that the new system cannot produce because the historical data was not migrated.
The remediation, which involves extracting the missing historical data from the decommissioned legacy system’s backup tapes, transforming it, and loading it into the live ERP, costs four times what the original six-week resource extension would have cost. The legacy system’s backup tapes are partially corrupted. Three years of data cannot be fully recovered.
The finance controller, when the situation is explained to him, is asked one question by the external auditors that he cannot answer without discomfort: “Were you informed that the historical data scope was being reduced?”
He was not. Because the PM reported Green.
The four additional resources that would have cost 4% of the project budget, approved in a fifteen-minute steering committee conversation in month nine, would have prevented a post-go-live remediation that cost 19% of the project budget and a tax audit finding that cost considerably more in management time and legal fees.
Bachane ki koshish mein, zyaada barbaad kar diya. In trying to save, we wasted far more.
The MES Example: The Vendor Call That Came Too Late
A steel plant is implementing an MES for its steelmaking and continuous casting operations. The MES vendor is responsible for delivering the heat scheduling module: the component that optimises the sequence of heats through the ELD, the converter, and the caster, accounting for grade transitions, equipment constraints, and downstream rolling requirements.
In month seven, the project manager notices that the heat scheduling module’s configuration progress has stalled. The vendor’s configuration lead, the only person on the vendor team who understands the plant’s specific grade transition constraints, has been partially reassigned to another client project. The heat scheduling configuration is being done by a junior resource who is learning the module as she goes.
The PM raises this bilaterally with the vendor’s project manager. The vendor’s PM acknowledges the situation and says the senior resource will be “re-engaged as needed.” Three weeks pass. The senior resource is not re-engaged. The configuration progress remains stalled.
The PM continues to report Green, reasoning that the vendor has acknowledged the issue and committed to a resolution.
In month ten, the integration testing for the heat scheduling module reveals that the grade transition logic has been configured incorrectly. The junior resource, without the domain knowledge of the senior configuration lead, has implemented a simplified transition matrix that does not reflect the plant’s actual metallurgical constraints. The module, as configured, would produce heat sequences that violate the caster’s tundish change requirements in approximately 15% of scheduling scenarios.
The reconfiguration requires the senior resource, who is now fully committed to the other client project and cannot be available for six weeks. The module’s go-live date slips by eight weeks. The overall MES go-live, which had been planned around the heat scheduling module being operational, slips by ten weeks.
Now consider the alternative. In month seven, the PM escalates to the steering committee: “The MES vendor has partially reassigned the senior configuration resource critical to the heat scheduling module. Bilateral engagement has not resolved this in three weeks. I am requesting that the committee formally escalate to the vendor’s regional account director to reinstate the resource commitment.”
The committee chair, a VP with a direct relationship with the vendor’s regional leadership, makes the call in month seven. The senior resource is reinstated within the week. The configuration completes correctly. The go-live proceeds on schedule.
Same problem. Month seven intervention versus month ten discovery. Zero schedule impact versus ten weeks of delay.
The steering committee had the leverage to solve this problem in a single phone call. The PM had neither the relationship nor the organisational authority to make that call herself. All that was required was the information, surfaced honestly, structured clearly, with a specific ask.
It was not surfaced. The call was never made. And the vendor, rational actors that vendors are, optimised their resource allocation for the client that was creating the most visible pressure, which was not this project, because this project was reporting Green.
Jo chillata nahi, uski baat nahi suni jaati. Those who don’t speak up don’t get heard.
The APS Example: The Cross-Portfolio Decision That Never Happened
A steel plant is implementing an Advanced Planning and Scheduling system covering production planning from slab allocation through hot rolling, cold rolling, and finishing. The APS implementation requires, for its constraint modelling, a subject matter expert who understands the hot strip mill’s equipment constraints in detail: roll change intervals, cobble recovery times, width transition rules, and the interaction between the rolling schedule and the downstream coiling constraints.
There is exactly one person in the plant who has this knowledge at the depth the APS configuration requires. He has been named as a key resource on the APS project from the beginning.
In month five, this person is pulled onto an emergency project: a quality excursion in the finishing mill that requires his expertise and is consuming approximately 60% of his available time. He is still nominally on the APS project but is contributing approximately four hours per week instead of the twenty hours the configuration plan assumed.
The APS project manager knows this. She has had several conversations with him about his availability. He is apologetic, committed to the APS project in principle, and genuinely unable to give it more time while the quality excursion is active.
She reports Green. Her reasoning: he is still engaged, the quality excursion will resolve itself, and raising the resource issue with the committee feels like complaining about something outside her control.
The quality excursion takes eleven weeks to resolve. During those eleven weeks, the APS configuration of the hot strip mill constraints proceeds with best-guess inputs from the project team, supplemented by whatever the subject matter expert can contribute in four hours per week. The configuration is approximately right. It is not precisely right.
In month thirteen, during APS pilot testing, the planning engine generates a rolling schedule that the hot strip mill operators immediately identify as operationally implausible. The roll change intervals in the model do not match the actual maintenance windows. The cobble recovery assumptions are optimistic by a factor that experienced operators find almost comical. The width transition rules are simplified to the point where the generated schedule would, in actual operation, produce yield losses that the business case for the APS system was specifically designed to eliminate.
The model reconfiguration requires eleven weeks of intensive work with the subject matter expert, who is now, at month thirteen, available. The APS pilot is delayed. The confidence of the plant operations team in the system is damaged, and damaged confidence in an APS system is a significant implementation risk, because an APS system that operators do not trust is an APS system that operators work around, and an APS system that is worked around has delivered precisely none of its promised value.
What the steering committee could have done in month five, had the PM escalated honestly: directed the operations function to formally protect the subject matter expert’s APS project allocation, even during the quality excursion, by bringing in additional support for the quality investigation from another source. The committee had both the visibility across the plant’s resource pool and the authority to make that reallocation decision.
What the steering committee actually did in month five: approved the Green status report and moved on to the next agenda item.
Why the Misunderstanding Persists: A Cultural Observation
There is a specifically Indian dimension to the steering committee performance problem that deserves acknowledgment, not to generalise unfairly, but because it is recognisable to anyone who has worked in this environment and pretending otherwise would be dishonest.
In many Indian organisational contexts, and this is as true in manufacturing as it is in IT services, there is a deep cultural discomfort with surfacing problems upward to senior leadership. It feels like an admission of inadequacy. It feels like burdening people who are already busy. It feels like, and this is the phrase that recurs, “making an issue out of it.”
“Arrey, itni baat kya hai? Ho jayega.” What is there to make such a fuss about? It’ll happen.
This disposition has genuine virtues in the right context. The ability to absorb and manage problems without constant escalation is a real professional skill. Operational resilience, the capacity to work around obstacles without requiring senior leadership to personally unblock every friction point, is genuinely valuable.
But it becomes pathological when it is applied to problems that are genuinely beyond the PM’s authority to resolve: when the PM absorbs what should be a steering committee intervention and carries it alone, quietly, while the window for effective intervention closes.
The cultural norm of jugaad, the celebrated Indian tradition of ingenious improvisation, has its place. A jugaad that solves a local problem without consuming governance bandwidth is excellent. A jugaad that substitutes for a governance decision that should have been made three months ago, and that embeds a workaround into a production system that will take two years to unravel, is not jugaad. It is a deferred disaster with a creative name.
Jugaad ka matlab temporary fix hai, permanent solution nahi. Jugaad means a temporary fix, not a permanent solution. The steering committee is the permanent solution mechanism. It should be used as one.
The Misused Committee: Three Patterns That Should Be Recognisable
Steering committees are misused in broadly three ways in large manufacturing software programmes, and all three produce the same outcome: a governance structure that looks functional from the outside and is hollow from the inside.
Pattern One: The Information Dump
The PM arrives with a comprehensive deck. Fifty-two slides. Every workstream covered. Beautifully formatted. Colour-coded. With trend charts.
The committee spends fifty minutes reading slides. Five minutes remain for discussion. No decisions are made. The committee disperses. The programme continues unchanged.
The PM has informed the committee. The committee has received information. Neither party has done anything with it.
A steering committee that spends its meetings consuming information rather than making decisions has been converted into a reporting audience. This is not governance. This is a very expensive status update, delivered to people who could have read a two-page summary in ten minutes.
Worse, such meetings end up as Chai-Buscuit meetings (Tea and Biscuits)
Pattern Two: The Approval Factory
Every agenda item is a request for approval on something that has already been decided. The project manager presents a recommendation. The committee approves it. This happens for eleven items. The meeting ends in forty minutes and everyone considers it efficient.
The problem: the committee’s approval is being sought for decisions that do not require steering committee authority. The decisions that do require steering committee authority, the uncomfortable ones, the resource conflicts, the vendor escalations, the scope trade-offs, are being handled elsewhere, or not at all.
The committee is approving everything except the things it needs to approve. It is being used as a rubber stamp for routine decisions while structural problems accumulate outside the meeting room.
Pattern Three: The Theatre Review
The steering meeting is, in effect, a performance. The PM and her team have prepared extensively. The committee has been individually briefed beforehand on anything sensitive. The agenda has been designed to minimise surprise. Questions have been anticipated and pre-answered in the deck.
The meeting runs smoothly. Decisions are made without friction. The committee leaves satisfied.
Nothing unexpected was surfaced because nothing unexpected was allowed to reach the room. The governance structure has been used to produce the appearance of control rather than the reality of it.
What the Committee Should Be: A Practical Picture
A steering committee meeting that is functioning correctly looks different from all three patterns above.
It is shorter than most programme teams expect. Sixty minutes is adequate for a well-prepared session, because the committee’s job is to make decisions, not to understand the project in detail.
It is driven by the PM’s agenda, not a committee-defined template, because the PM knows what decisions the programme needs from the committee this fortnight, and those decisions should drive the agenda.
It contains at least one item that the PM is genuinely uncertain about: a decision where she has options but does not have the authority or the full information to choose between them herself.
It produces decisions that are recorded, owned, and followed up: not “noted” or “taken on board,” but assigned to a named individual with a completion date that appears on the next meeting’s agenda as a standing item.
And it treats the PM who surfaces a difficult escalation with structured options as a professional who is using the governance framework correctly, not as someone who has failed to manage her project well enough to avoid needing the committee’s help.
Because needing the committee’s help is the point. Committee banai hi isliye gayi thi. That is why the committee exists.
Tips for Project Managers: How to Use the Committee as the Resource It Is
One: Enter every steering meeting knowing exactly what you need the committee to decide.
Not what you want to tell them. What you need them to decide. These are different things. Telling the committee that the vendor interface is delayed is information. Asking the committee to formally escalate to the vendor’s regional director by a specific date, and getting that commitment in the meeting, is a governance output.
Before every steering review, complete this sentence: “By the end of this meeting, I need the committee to have decided…” If you cannot complete the sentence, you are not using the meeting correctly.
Two: Bring options, not just problems. But do not wait for perfect options.
The structured escalation format exists because it gives the committee something to act on. Problem plus options plus specific ask equals a governable situation. Problem alone equals a committee that does not know what to do with the information.
But do not wait to escalate until you have perfect options. An early escalation with two imperfect options is worth ten times more than a late escalation with a beautifully constructed recommendation. The committee’s value is in their authority and relationships, not in their ability to evaluate perfect solutions. Give them something to decide on, early, even if the decision is imperfect.
Three: Name the committee member who can solve your problem.
In every escalation, think specifically about which person in the room has the authority, relationship, or resource to resolve the issue. Name it in your escalation, even indirectly: “Resolving this vendor situation will require engagement at a level above the project team. The vendor’s regional account is managed by a committee member in this room.”
This is not manipulation. It is precision. It tells the committee specifically how their authority maps to your problem, which makes it easier for the right person to volunteer or be directed.
Four: Follow up on committee commitments like your project depends on it, because it does.
When a steering committee member commits to an action, a call, an approval, a decision by a date, that commitment needs to be tracked with the same rigour as any project milestone. It goes in the action log. It appears on the next agenda. If it has not been completed, it is raised, politely, professionally, but raised.
Committee members are busy people who will deprioritise a project action item if it is not visibly tracked. The PM who allows committee commitments to slip without follow-up is the PM who teaches the committee that its commitments do not have consequences, and a committee that learns this lesson will make fewer of them.
Tips for Steering Committee Members: How to Be the Resource the Programme Needs
One: Ask “what do you need from us?” before asking “why did this happen?”
The sequence of committee questioning matters enormously for the information environment it creates. A committee that responds to every escalation with a root cause investigation teaches PMs to bring only escalations they have already resolved, which defeats the purpose of escalating.
The first question in response to any escalation should be about the forward path, not the backward cause: “What do you need from us to move this forward?” The root cause analysis can happen in a separate session, once the problem is addressed. In the steering meeting, the committee’s energy should go toward the decision, not the debrief.
Two: Make decisions in the room, not after it.
A committee that consistently takes items “under advisement” and provides decisions offline is a committee that is functioning as a consulting body rather than a governance body. Governance requires decisions. Decisions require the decision-makers to be in the room together, with the information in front of them.
If an item requires more information before a decision can be made, the committee should say so explicitly: name what information is needed, who will provide it, and by when the decision will be made. Not “we’ll come back to this,” but “We need X from Y by the fifteenth. We will make this decision at the next steering review.”
Three: Volunteer your relationships before being asked.
A steering committee member who hears about a vendor escalation issue and thinks “I know their regional director” should say so in the room, immediately, without waiting to be asked: “I have a relationship with their regional account. Let me make a call this week.”
This kind of proactive offer, a committee member actively connecting their personal authority to the programme’s specific need, is what steering committee membership is for. It is not about hierarchy or seniority. It is about the specific deployment of specific relationships at the specific moment when they are most useful.
Four: Protect the PM who brings you bad news publicly.
When a PM surfaces a difficult escalation in a steering meeting, one that reflects genuine programme complexity and not negligence, the committee chair’s visible response to that escalation is a signal to every other workstream lead in the room.
A response that is supportive, decisive, and action-oriented teaches the room that honest escalation is rewarded. A response that is interrogative, critical, or visibly uncomfortable teaches the room that honest escalation is costly.
The chair of a steering committee has, in this moment, more influence over the programme’s information culture than any governance framework or reporting standard. Use it consciously.
The Final Point
The steering committee is not a performance venue. It is a deployment mechanism for authority that the delivery team does not possess.
It can only deploy that authority against problems it knows about. It can only know about problems that are surfaced honestly, structured clearly, and brought to the table with a specific ask, while there is still time for the authority to be useful.
The PM who treats the committee as an audience has not protected her project from scrutiny. She has protected her project from help.
And in a large ERP, MES, or APS implementation in a steel plant, where the vendor ecosystem is complex, the operational constraints are unforgiving, and the window for effective intervention closes faster than anyone expects, help deployed early, at the right organisational level, is the single most valuable resource on the programme.
It is sitting in the room with you every fortnight.
Use it, yaar. Just use it.
Have you sat on a steering committee that found out it had been performing governance rather than practising it? Or been the PM who finally used the committee correctly and watched a problem dissolve that had been festering for months? The comments are open, and this particular conversation, I think, has a lot of stories in it.
#ProgrammeGovernance #SteeringCommittee #ERPImplementation #MESImplementation #APSImplementation #SteelManufacturing #ProjectManagement #HonestLeadership #DeliveryExcellence #DigitalTransformation #IndianManufacturing #ExecutiveLeadership #RiskManagement
Disclaimer: The incidents, characters, projects, and organisations referenced in this article are fictionalised composites drawn from recurring patterns observed across complex transformation programmes. Their purpose is to illustrate leadership and governance lessons rather than describe any specific organisation, project, customer, or implementation. The lessons, however, are very real.