Project steering committee: who decides, and who only advises

On a large programme under contract, the same week can carry a steering committee, a project review and a contractual milestone. All three get called governance, and the invitations rarely say which is which. Only one of the three commits the organisation to anything, and the people in the room do not always agree on which one.

The steering committee: the body that decides

ISO 21502:2020 does not start from the meeting, it starts from the authority. Project governance, at 4.3.1, is “the principles, policies and frameworks by which an organization directs, authorizes and controls the project based on an agreed business case”, and what it oversees includes “roles and responsibilities, including limits of authority for decision-making”. A steering committee is not a meeting where people are informed. It is where an organisation’s authority stops being general and becomes bounded, for one project.

Who carries that responsibility is the first thing the standard settles, and it is not what most articles assume. In the same clause, the responsibility for maintaining project governance “is usually assigned by the governing body of the sponsoring organization to the project sponsor or project board”. The accountable individual is the sponsor. The board is conditional: 4.5.3 opens with “The project board, if needed, should contribute to the project by providing direction and guidance to the project sponsor”.

From there, two mountings, and both are normative. A project board can be “either a governance body, representing the higher-level authority to which the project sponsor is accountable”, or “a board, chaired by the project sponsor, which provides the sponsor with senior-level advice” (4.5.3). These are not two styles of running the same meeting. In the first, the committee sits above the sponsor and can overrule them. In the second, the sponsor runs the committee and takes its advice.

Two live referentials each settle it, in opposite directions, and each is coherent with itself. PRINCE2 7 takes the first: “All PRINCE2 projects must have a project board”, built from the project executive, senior user and senior supplier roles (6.2.4.4), and the project executive is “the single point of accountability for the project”, neither delegable nor combinable with the project manager (6.2.4.1). The PM² Methodology Guide v3.1 takes the second: the Project Steering Committee “is chaired by the Project Owner (PO) and is the key decision-making and issue-resolution body for the project” (4.4). It “Authorises transition between Phases unless this is performed by the Appropriate Governance Body (AGB)” and “has the final say on decisions”, while the AGB above it is “the body with the authority to approve a project, agree its stated objective and release the funding required to implement it” (4.3).

The name comes last, and it is the one the search box asks for. ISO 21502:2020 calls the body a project board, and its NOTE at 4.5.3 records the rest: “Commonly used terms for project boards include, but are not limited to, ‘project steering group’, ‘project steering board’, ‘project steering committee’ or ‘governance committee’.” The term most practitioners use is, in the standard’s own words, a common name rather than the standard’s name.

One referential names no body at all, and the silence is worth knowing about. The PMBOK Guide, 6th Edition (2017) carries no occurrence of “steering committee”; its governance definition at 2.4.2.2 is deliberately abstract, “the framework, functions, and processes that guide project management activities”, and it refers the reader to a separate practice guide. In the PMBOK Guide, 7th Edition (2021) the phrase surfaces only in figure 2-2, a list of stakeholder examples.

The review: it examines, it does not decide

A review is dated, and it is run by people who are not running the project. ECSS-M-ST-10-01C (2008) puts it plainly at 4.1: “Project reviews are examinations of the technical status of a project and associated issues at a particular point in time.” Independence is structural rather than a matter of good intentions: the review authority is “chaired by an independent representative of the consumer organization”, and the review team “shall include representatives of the consumer organization having no direct involvement in the project activities” (5.2).

At NASA that independence is a procedure with paperwork. Standing Review Board members are selected from outside the programme or project management chain, organisational and personal conflicts of interest are screened separately for civil servants and for contractors, contractor members are re-checked annually, and a waiver runs up to the Administrator’s signature (NASA Standing Review Board Handbook, Revision C, 2023, 1.4.5 and 3.2).

Then comes the sentence that settles the question, from the same handbook at 1.4.2: “SRBs have an advisory role. The SRB conducts the LCRs and can provide recommendations, but the SRB members and consultants-to-the-board do not impose requirements on, make decisions for, or direct the program or project.”

The British system says the same thing three times over, in a preamble common to its whole gate series. A gate review “provides a snapshot view of progress at a point in time and, therefore, should be seen as complementary to these internal processes, and not a replacement for them”; the fact that one has taken place “does not replace the need for a full audit opinion on the effectiveness of risk management, control and governance”; and “none of these review processes is a substitute for a rigorous governance framework in the organisation” (Infrastructure and Projects Authority, Gate Review Process, Gate 3 Review: Investment Decision, V1.0, July 2021).

What a review produces is not a decision either, and the vocabulary is explicit. A finding is “a conclusion reached by the SRB based on examination or investigation”; a concern is a minor weakness, “not a discriminator in and of itself” (Standing Review Board Handbook, Annex A). In the European space standard, a RID is “an issue, identified by a reviewer, that is not compliant with a requirement, a review objective or a design goal” (ECSS-M-ST-10-01C, 3.2.3). Findings, concerns and RIDs oblige someone to answer. None of them authorises anything.

One warning before leaving the subject: there is no shared taxonomy of reviews, and anyone offering one has invented it. MIL-STD-1521B lists ten technical reviews and audits (1.2). ISO 10006:2017 knows two kinds, management reviews and progress evaluations (5.3.1 and 5.3.2). NF X50-115:2017 groups them in three families, contractual, governance and technical (5.1.4). Three counts, three logics, each current in its own domain.

The decision point: it authorises, and it is signed

The third object is neither a body nor a meeting. It is an instant. ISO 21502:2020, at 4.4: “Each phase should be preceded by a decision point. These decision points, often referred to as ‘gates’, are essential aspects of project governance.” The criteria that must be met “to authorize the start of a phase should be defined”.

NASA names the same object and says who owns it. Key decision points are “the events at which the decision authority determines the readiness of a program/project to progress to the next phase of the life cycle” (NASA Systems Engineering Handbook, Revision 2, 2016). PM² marks three of them, RfP, RfE and RfC, at the end of the Initiating, Planning and Executing phases (PM² Methodology Guide v3.1, 3.2.6).

The clearest sentence in the whole corpus is the one that joins the three objects together. A NASA life-cycle review held at the end of a phase “is complete when the governing Program Management Council and Decision Authority complete their assessment, make the decision to authorize a program or project to progress to the next life-cycle phase, and sign the Decision Memorandum” (Standing Review Board Handbook, 2.1). The review ends where the decision begins, and the decision is signed.

Which is where English makes the confusion easy. PM² calls what sits at the end of a phase “a review and approval gate”, in one breath (3.2.6). The Infrastructure and Projects Authority titles each of its workbooks a Gate Review, and workbook 3, Investment Decision, covers the work “up to contract signature or agreement to place work with an existing supplier or partner”. The examination and the authorisation share a word in English. They do not share a signature.

What each one does under contract

The body decides inside its mandate and sends the rest upward. ISO 21502:2020 describes the escalation at 4.5.2: the sponsoring organization “acts as a higher-level authority and should provide direction and resources to the project board or the project sponsor, address escalated risk and issues and make or refer decisions that are above the delegated authority of the project board or the project sponsor”. The sponsor, symmetrically, makes “decisions within their delegated authority” and escalates “risks and issues beyond their delegated authority to the higher-level authority” (4.5.4). NF X50-115:2017 puts the same requirement on the organisation itself, recommending that it constitute a governing body, or designate the authority the project or programme manager reports to, tasked with taking the decisions that exceed that person’s mandate and with arbitrating conflicts (7.2).

The review obliges an answer, not obedience. At NASA the escalation is a sequence: the board debriefs the project, then “briefs the management councils leading up to the appropriate governing PMC”, with “an overall pass/fail recommendation” within thirty days (Standing Review Board Handbook, 5.8). A pass or fail recommendation reads like a verdict and still is not one. The decision is taken and signed elsewhere.

Under contract, the review is owed because the contract says so. MIL-STD-1521B, revision B of 4 June 1985, required technical reviews and audits to be conducted “to the extent specified in the contract clauses, Statement of Work (SOW), and the Contract Data Requirements List” (1.3), and it tied the trigger to maturity rather than to the calendar: the system requirements review “will be conducted when a significant portion of the system functional requirements has been established” (3.1). That is a United States defence standard, since withdrawn, and it prescribed for its own domain. What travels is the shape: a review named in the contract is a deliverable, not a courtesy.

The decision point sits before the commitment, and that is its whole reason for existing. Government Functional Standard GovS 002, version 2.1 (2025), is unambiguous at 4.2.3: “Assurance reviews shall be scheduled prior to significant decisions (such as contractual commitments and gates) to provide decision makers with an assessment of the status and outlook for the work”, with a maximum of one year between two assurance reviews. The Infrastructure and Projects Authority draws the same line at gate 3, which stops at contract signature. The review comes before the signature. It does not record it.

Where these three come from

Three lineages can be dated on the documents themselves. The fourth, the most common of all, cannot.

1968, NASA: the decision points came first

NHB 7121.2, Phased Project Planning Guidelines, in its August 1968 edition, states at 2.1.d: “The Administrator has selected four major management decision points within the evolution of a project which are of special significance and importance in the management of the Agency’s program and resources.” The next paragraph draws the consequence: “These decision points divide the planning and definition process into three phases followed by an implementation phase” (2.1.e). Phases A to D follow from the decisions, not the other way round, and the document confirms it from the other end: “The work content of each of the first three phases is directed toward developing information needed to support the next major decision” (2.3.a).

The reason given is worth reading fifty-eight years later. Risk grows with the degree of technological advance, and the arrangement gives management “a disciplined basis for management to (1) evaluate project planning effort at critical points, (2) be cognizant of and thereby in a position to preserve significant future options, and (3) optimize the pay-off of the effort” (2.1.a and 2.1.b). The gate was invented to keep options open, not to add a checkpoint.

1976 at the latest, the United States Department of Defense: the review becomes contractual

MIL-STD-1521A (USAF) is dated 1 June 1976, established by the title page of revision B that superseded it. What this lineage contributes is not the review itself but its legal footing: the review is owed under the contract, the statement of work and the contract data requirements list, not under a custom.

1999, then February 2001, the United Kingdom: the gate becomes public policy

Peter Gershon’s Review of Civil Procurement in Central Government, April 1999, creates the Office of Government Commerce by merging several existing procurement bodies (recommendation B.9). The same report sets out the principles of what became the Gateway, at recommendation C.7: “projects have distinct phases in their life-cycle; the ‘gates’ between these phases can be characterised by sets of deliverables; deliverables should be assessed by people with relevant expertise who are independent of the project; important ‘gates’ (typically 3 in the life cycle) can only be passed as a result of successful reviews chaired by senior people who have no vested interest in the outcome of the review.”

Two precautions. The word “gateway” appears nowhere in that report: Gershon set out the principles, he did not name the thing. And he writes “typically 3” gates where the delivered scheme has six, numbered 0 to 5; none of the documents we hold explains how one became the other. Gateway reviews were made mandatory in February 2001 for high and medium risk projects (House of Commons, Committee of Public Accounts, Twenty-Seventh Report of Session 2004-05, HC 555, ordered to be printed 6 April 2005). The labels have moved since: gate 2 went from “Procurement strategy” to “Delivery Strategy”, and gate 5 from “Benefits evaluation” to “Operations Review and Benefits Realisation” (Infrastructure and Projects Authority, Gate Review Process, V1.0, July 2021).

The committee itself: no dated origin

The oldest attestation we hold is the AFITEP Dictionnaire de management de projet, 3rd edition (1996), a trilingual dictionary that already gives “steering committee” as the English equivalent of the French “comité de pilotage”, and that distinguishes a client-side committee from one set up inside the supplier. That is an attestation, not an origin. We can date the most technical of the three objects to the month, and not the most common one.

In short

The three objects are told apart by their signature, not by their attendance list. A standing body signs decisions, inside an authority that someone bounded on purpose. A dated event produces findings, which oblige an answer and authorise nothing. A decision point is the instant a signature moves a project into its next phase.

So before the next entry in the diary, the question worth asking is what leaves the room: a decision, a set of findings, or an authorisation. When nobody present can answer it, the meeting has no nature yet, and that is worth more attention than its agenda.

Stop guessing. See the real impact.

Frequently asked questions

Q.Does a project need a steering committee?

It depends on the referential. ISO 21502:2020 makes the board conditional, "if needed", and assigns governance to the project sponsor or the project board (4.3.1 and 4.5.3). PRINCE2 7 is categorical: all PRINCE2 projects must have a project board (6.2.4.4).

Q.How often should a steering committee meet?

No referential in our corpus fixes a cadence. The only interval any of them sets is in GovS 002 v2.1 (2025): a maximum of one year between two assurance reviews, and that bounds reviews, not committees. A monthly rule is a habit, not a standard.

Q.Is a steering committee the same as the project organisation?

No. The committee is a decision-making body with a bounded authority. The project organisation is what ISO 21502:2020 at 4.5.1 calls "a temporary structure that defines roles, responsibilities and authorities in the project". One decides, the other executes.

References

• AFNOR - NF X50-115 - Management de projet et de programme, présentation générale - Décembre 2017
• AFNOR, AFITEP - Dictionnaire de management de projet français-anglais-espagnol - 3e édition, 1996
• AXELOS - PRINCE2 7 - Managing Successful Projects - 2023
• Department of Defense - MIL-STD-1521A (USAF) - Technical Reviews and Audits for Systems, Equipments, and Computer Software - Revision A of 1 June 1976
• Department of Defense - MIL-STD-1521B - Technical Reviews and Audits for Systems, Equipments, and Computer Software - Revision B of 4 June 1985
• ECSS - ECSS-M-ST-10-01C - Space management, Organization and conduct of reviews - 2008
• House of Commons, Committee of Public Accounts - House of Commons, Committee of Public Accounts, Twenty-Seventh Report of Session 2004-05 (HC 555) - Session 2004-05, ordered to be printed 6 April 2005
• Infrastructure and Projects Authority - Gate Review Process - Gate 3 Review: Investment Decision - V1.0, 2021
• ISO - ISO 21502:2020 - Project, programme and portfolio management, Guidance on project management - 1st edition, 2020
• ISO - ISO 10006:2017 - Management de la qualité, lignes directrices pour le management de la qualité dans les projets - 3rd edition, 2017
• IT Governance Institute - COBIT Control Practices: Guidance to Achieve Control Objectives for Successful IT Governance, 2nd Edition (ISBN non établi) - 2nd edition, 2007
• IT Governance Institute - COBIT 4.1 - 2007
• NASA - NASA/SP-20230001306 - Standing Review Board Handbook - Revision C, February 2023
• NASA - NHB 7121.2 - Phased Project Planning Guidelines - August 1968 edition, initial publication of the implementation guidelines for the Phased Project Planning concept prescribed by NPD 7121.1A
• NASA - NASA SP-2016-6105 - Systems Engineering Handbook - Revision 2, 2016
• Office des publications de l'Union européenne - PM² Project Management Methodology Guide 3.1 - EN, 2023
• Peter Gershon - Review of Civil Procurement in Central Government (rapport Gershon) - April 1999
• PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 7th Edition - 2021
• PMI - A Guide to the Project Management Body of Knowledge (PMBOK Guide) - 6th Edition - 2017
• UK Government - Government Functional Standard GovS 002 - Project delivery - Version 2.1, 2025