Why a Steering Committee Cannot Write a Project Request

I have watched steering committees mistake authority for firsthand knowledge. They can approve spending and settle tradeoffs. They still cannot explain why the clerk exports, renames, and emails the same file every Friday.

Someone on the tenth floor says, in ordinary English, that “we need a portal.” Then the room decides that sentence is enough to be real. A charter appears. A RAID log appears. A slide titled “Alignment” appears, which is a polite way of saying nobody asked the clerk what Friday looks like.

A steering committee exists to decide. It does not exist to witness. Lean organizations still invite it to write the request because the meeting is already on the calendar. That is how “improve customer experience” becomes a funded rumor with quorum.

Four facts. Then stop.

The substitute for a steering pack is not a thinner pack. It is a shorter path.

A BA facilitates the intake conversation and records the account of the person who lives the problem. A reviewer checks whether a stranger can retell it. Everyone else waits until that story exists. I have seen forty-person companies do this in a week. I have also seen two-hundred-person companies spend a quarter producing a packet nobody on the floor can use.

• Submitter: the person living the broken process
• Committee check: can everyone retell the same current week?
• Committee decision: yes, no, or not yet—with a reason

That is the entire first artifact. Preferred vendors can wait. Architecture opinions can wait. The go-live date that someone invented in the elevator can wait. If two of those facts are missing, do not schedule steering. Steering is an expensive séance. Send back the two missing answers.

Put the paragraph on a record, not in a shared myth

Steering decks age between meetings. Their summaries become a second source of truth, and the approved slide eventually outranks the request. I have watched testers verify that summary while the clerk’s original complaint sat untouched.

Use software project intake so the same record reaches review with a BA facilitating the conversation without translating away the business voice. The submitter is an operations lead, a department manager, or the person who still runs the workaround on Fridays. A steering sponsor is not a required author. I have never seen a required-sponsor field make a request clearer. I have seen it make a request late.

The software delivery management features path gives the committee a cleaner job: review the same request, ask questions, consider estimates, and record a decision. It does not need a translated steering packet when the underlying page is already clear.

Review for understanding, not for polish

Ready enough means a stranger can understand the week. It does not mean the request sounds like a steering document. Missing solution design is expected. Missing who hurts is not.

If one committee rewrites every submission, congratulations. You hired a project office and gave it a nicer calendar. Review for gaps. Leave the voice alone. The Anti-PMO playbook for software intake is the operating model I wish I had been handed on day one: who submits, who reviews, and what “ready” means. If this pattern already owns the queue, start with fixing the broken business project intake process.

A recorded yes, no, or not yet lives on the request. Delivery tools receive work that already survived that gate. That is how a lean company moves software without a steering séance—and without pretending a thinner pack is the same thing as understanding.