Preparing for Steering Committee Meetings

Some professional moments arrive with very little warning. A stakeholder asks for one more thing in the middle of a meeting, and the request sounds reasonable on its own terms. The difficulty is that the request, if accepted, would quietly change what the team has promised to deliver. Nothing in the request looks like a crisis, which is exactly why it is easy to say yes to it on the spot.

This article follows one such moment from a forward deployed engineer's year. The scenario is the anchor for the whole article. As you read, keep one practical question in mind: what made the difference between an answer that protected the project and an answer that would have put it at risk?

The key phrase is specific words. The practice is not a general intention to handle a tricky moment well. It is the deliberate preparation of actual sentences you expect to say. A situation qualifies for this kind of preparation when you can anticipate it: a senior stakeholder raising a new request in a formal meeting is a situation that many project leads can see coming, even if they cannot predict the exact wording.

Maya's solo engagement ran from month five through month nine. It was for a larger insurance carrier, involved a more complex mix of case classes, and had a twelve-week timeline. She had no shadow on this engagement. The first six weeks went well, and the discovery and validation work felt familiar by then. The moment that defined her year came in week seven.

During a steering committee meeting that Maya was running, the customer's deputy CIO pushed for an addition to the scope. The addition would have broken the timeline. The situation had three features worth noticing: the request came from a senior stakeholder, it came in a formal meeting, and the cost of the request was tied directly to the schedule rather than to a single task.

The diagram is a description of what happened in the source scenario, with the improvised branch shown as the risk the source warns about. The source says the request, if accepted, would quietly change what the team has promised to deliver. An answer given without a prepared line is the situation where that acceptance can happen by accident.

Scope creep is the gradual or sudden expansion of what a team has committed to deliver. In Maya's case it arrived as a single request in a meeting. Seen as a sequence, the moment has stages, and a prepared response fits at one specific point in that sequence.

Read the flowchart from top to bottom. The request is raised first. Next, it is checked against the timeline, because the source says that check has to come before a response is chosen. Only then is the prepared response selected. The response acknowledges the team's preference for the original work and then offers a follow-on engagement for the addition. The final stage is the protected original delivery.

The stages show why timing matters. The rehearsed line does not replace the timeline check. It is the response you reach for after you have checked the request against the commitment. Each step depends on the one before it. If the check is skipped, there is no reliable basis for choosing the response, and if the response does not offer a route for the addition, the original delivery is put at risk.

The line Maya used was: I would rather land the original delivery on schedule and start a follow-on engagement for the addition. The source describes the response as acknowledging that the team would rather deliver the original work on schedule, and then proposing a follow-on engagement. Reading the sentence in order shows how those two moves are built into the words.

The first part states a preference rather than a refusal. The second part names the committed work and its schedule. The third part offers the addition a route of its own. The final part makes clear what the offer concerns. Because the sentence is spoken aloud in a particular order, a learner who has practiced it can deliver each part without having to work out the structure during the meeting.

A rehearsed line only helps if it is delivered in a way that protects the commitment. The source shows what Maya avoided, and those choices can be turned into a checklist of common errors. The items below are drawn from the logic of the scenario rather than from a separate list in the source.

The same approach works for a situation you can anticipate. Start by naming a request you expect to hear, one that sounds reasonable but would change what your team has promised. Check it against the timeline, then draft a response that acknowledges the commitment and offers a separate path for the request. Practice the words aloud until they come easily.