3.2.1: Governance Architecture and Decision Bodies

Governance Architecture 

Governance gives a portfolio its formal structure of authority. Without it, every funding decision becomes a fresh negotiation, decided by whoever has the most political capital in the room that day. Two bodies sit at the center of most governance architectures, and it's worth being precise about how they differ.

Steering Committee Versus Governance Board

A steering committee oversees the delivery of governance policies and procedures. It exists to help project teams stay on track and keep delivering results, and it usually sits at the PMO level or the portfolio level. A governance board sits above that. It approves portfolios and acts something like traffic police across the entire organization, deciding which investments move forward and making sure different divisions aren't accidentally working against each other.

The distinction isn't just about seniority. It's about the kind of question each body is built to answer. A steering committee asks whether a project is on track. A governance board asks whether a project should exist at all, and whether it deserves the organization's limited capital more than something else competing for the same money.

Authority Styles and How They Shape a Portfolio

Governance bodies define who holds decision rights on paper. What actually happens once those rights are exercised depends heavily on the authority style running underneath them. Two portfolios can have identical RACI charts and produce very different results, simply because one governance board decides by consensus and the other decides by one executive's word.

A few common styles show up repeatedly across organizations, and each one trades speed for something else. Table \(\PageIndex{1}\): Authority Styles and Their Trade-Offs lays out how different decision-making styles affect speed, buy-in, and risk in a portfolio.

Table \(\PageIndex{1}\): Authority Styles and Their Trade-Offs  

Style	Speed	Main Risk
Top-down (one decision maker)	Fast	Blind spots go unchallenged, and buy-in from the team is often weak
Consensus (everyone agrees)	Slow	Decisions stall, and the loudest objection can block real progress
Consultative (one owner, many inputs)	Moderate	Requires real discipline to avoid sliding into either extreme
Delegated (pushed to the lowest capable level)	Fast at the local level	Portfolio-wide coherence can suffer if nobody is watching the pattern across decisions

A top-down, almost dictatorial style can move a portfolio forward quickly, since one person's word is enough to unstick a stalled decision. The cost shows up later. A single decision maker can't personally catch every risk, and a team that's never asked for input tends to execute half-heartedly, or quietly hopes to be proven right when the decision goes badly. Speed on paper doesn't always translate into speed in practice, since a team that doesn't believe in a decision often finds subtle ways to slow it down anyway.

Consensus sits at the opposite end. It produces strong buy-in, since everyone had a real hand in shaping the outcome. It also has an obvious cost. Getting a large group to fully agree takes time, and in a fast-moving portfolio, that time is often the thing the organization can least afford. A single stakeholder who refuses to sign off can hold an entire decision hostage, even when their objection is minor compared to the value being lost by waiting.

Myth

A common assumption is that consensus is always the safest, most responsible way to decide, since it involves the most people and the least risk of one person's ego driving the outcome. In reality, consensus can be its own kind of risk. It can produce watered-down decisions that satisfy nobody fully, and it can let a portfolio drift while everyone waits for everyone else to agree. Involving more people isn't automatically safer. It's a trade-off, the same as any other authority style, and it needs to be chosen deliberately rather than assumed to be the responsible default.

Most well-run portfolios end up somewhere in the middle, using a consultative style. One person or one body genuinely owns the decision and is accountable for it, but that owner is expected to actively pull in input from the people who will be affected before finalizing the call. This keeps the speed advantage of having a clear decision maker while avoiding the blind spots that come from deciding in total isolation. It takes more discipline than either extreme, since it's easy for a consultative process to quietly slide into either a rubber-stamped top-down decision or an accidental consensus process that never actually closes.

The right style also isn't fixed for every situation. A portfolio manager facing a fast-moving crisis, like the kind of sudden shift discussed earlier in this chapter, may need to lean toward a faster, more top-down call simply because there isn't time for broad input. A long-term strategic realignment, where buy-in from multiple departments will determine whether the change actually sticks, may be worth the slower pace that comes with a more consultative or consensus-driven process. Matching the authority style to the situation, rather than defaulting to whatever style the organization happens to be culturally comfortable with, is part of what makes a governance model actually work in practice.

Who Actually Sits on Each Body

Real staffing patterns make the difference concrete. A governance model built for a product design portfolio might put the portfolio manager, business leadership, and engineering or IT leadership on the steering committee, alongside relevant stakeholders. Its governance board would then pull in legal advisors, PMO advisors, and senior leadership roles like the chief operating officer, vice presidents, and directors.

A governance model built for an electric vehicle portfolio might look different in its specifics but follow the same shape. The steering committee could include the portfolio manager, chief financial officer, technical architect, chief sales officer, and chief legal officer. Its governance board might then include the chief administrative officer, general counsel, chief financial officer, chief information officer, chief coordinating officer, and chief operating officer. Table \(\PageIndex{2}\): Steering Committee Versus Governance Board lays out how the two bodies typically differ in focus and staffing.

Table \(\PageIndex{2}\): Steering Committee Versus Governance Board  

Aspect	Steering Committee	Governance Board
Core question	Is this project on track?	Should this project be funded at all?
Typical level	PMO or portfolio level	Senior executive level
Typical members	Portfolio manager, business leadership, technical leadership	Chief officers, legal advisors, senior directors
Authority	Oversees delivery and keeps work moving	Authorizes capital and resolves cross-division conflict

Notice the pattern across both examples. Steering committees are staffed by people close to the actual work, people who can answer detailed questions about schedule, budget, and technical risk. Governance boards are staffed by senior executives who can authorize capital and resolve conflicts between competing divisions. Mixing these two roles up, or assuming they're interchangeable, leads to slow decisions and unclear accountability.

Myth

A common assumption is that the PMO and the governance board are the exact same entity, with interchangeable approval authority. They aren't. The PMO typically supports and standardizes how portfolios operate. The governance board is the body that actually authorizes capital and settles disputes between divisions. Treating them as one and the same blurs a distinction that matters the moment two departments disagree about funding.

Getting this architecture right early protects the organization from a very specific failure mode. If the same small group both proposes an initiative and approves its own funding, there's no independent check on that decision. Separating oversight from authorization is what keeps a governance model honest.

Authority Models and Decision Rights 

Even with clear governance bodies in place, someone still has to spell out who actually does what on any given deliverable. This is the purpose of a Responsibility Assignment Matrix, often built using the RACI method. Without it, a governance board can approve a project and still leave everyone underneath it guessing about who's actually supposed to act.

The Four Roles in a RACI Matrix

Each letter in RACI marks a distinct role. R means responsible, the person who actually does the work. A means accountable, the person who owns the outcome and answers for it. C means consulted, typically a subject matter expert brought in for input before a decision is made. I means informed, someone who needs to know what happened but isn't directly involved in making the decision.

These four roles sound simple written out, but most organizations blur at least one of them without realizing it. The most common mix-up is treating "consulted" and "informed" as the same thing. A consulted stakeholder gets a real say before the decision is finalized. An informed stakeholder just gets told afterward. Confusing the two either slows a decision down by looping in people who don't need to weigh in, or blindsides people who genuinely should have had a voice.

Worked Examples Across Different Portfolios

Real RACI charts show how this plays out differently depending on the work. A product design portfolio might assign accountability for project documentation to the portfolio and PMO function, while business leadership holds accountability for market fit requirements and engineering leadership holds accountability for functionality engineering, with stakeholders kept informed throughout.

A digital marketplace expansion effort might split accountability and consultation across portfolio managers, financial managers, IT architects, the PMO, and marketing and sales, sometimes assigning shared accountability and consultation to the same role on a single deliverable when that reflects how the work actually gets done. An electric vehicle portfolio might assign the portfolio manager as responsible for deciding release dates and goals, with the chief sales officer accountable, while the technical architect holds both responsibility and accountability for defining the product vision. Risk management might sit with the portfolio manager as responsible, while acceptance criteria sit with the technical architect as responsible and the portfolio manager as accountable. Table \(\PageIndex{3}\): A Sample RACI Assignment lays out how responsibility and accountability might split across roles for a set of common portfolio deliverables.

Table \(\PageIndex{3}\): A Sample RACI Assignment  

Deliverable	Responsible	Accountable	Consulted
Release dates and goals	Portfolio Manager	Chief Sales Officer	Technical Architect
Product vision	Technical Architect	Technical Architect	Portfolio Manager
Risk management	Portfolio Manager	Chief Financial Officer	PMO
Acceptance criteria	Technical Architect	Portfolio Manager	Business Leadership

Notice that responsibility and accountability don't always sit with the same person, and that's intentional. The person doing the work isn't always the person who should answer for the outcome if something goes wrong.

Myth

It might seem safer to assign more than one person as accountable for a single decision, since more oversight should mean more safety. In practice, this usually backfires. When two people are both accountable, neither one feels fully on the hook, and decisions stall while each waits for the other to act. Single-point accountability isn't about limiting oversight. It's about making sure someone can't quietly hide behind a shared title when a decision needs to actually get made.

Clear, single-point accountability, paired with well-defined consultation and information paths, is what lets a matrixed or functional organization move quickly without constant escalation. It also gives the escalation process something concrete to point to when something does go wrong, since everyone already knows exactly who owned the decision.

Beyond RACI: The CAIRO Model for Confidential Work

RACI answers a simple question well. Given that everyone involved is allowed to know what's happening, who does what? That assumption, that everyone involved can safely know everything, breaks down completely in certain kinds of work. Some portfolios involve information so sensitive that deciding who should be kept out of the loop is just as important as deciding who's responsible for the work itself.

This is where the CAIRO model comes in. It extends RACI by adding a fifth category: Omitted. The full breakdown is Consulted, Approver, Responsible, Informed, and Omitted. The first four roles work much the same way they do in RACI, though CAIRO often separates "Approver" from a broader accountable role to make final sign-off explicit. The real addition is the fifth category, and it's not a minor add-on. Naming who is deliberately excluded from a decision is a governance act in its own right, not an oversight. Table \(\PageIndex{4}\): RACI Compared to CAIRO lays out how the two models differ, with CAIRO's added role highlighted.

Table \(\PageIndex{4}\): RACI Compared to CAIRO  

Role	In RACI	In CAIRO
Responsible	Does the actual work	Does the actual work
Accountable / Approver	Owns the outcome	Gives final sign-off on the decision
Consulted	Gives input before the decision	Gives input before the decision
Informed	Told after the decision	Told after the decision
Omitted	Not a defined role	Deliberately excluded, on a need-to-know basis

For most portfolios, an omitted category would seem strange, even exclusionary. In a portfolio built around real secrecy, it's the whole point. A company developing a product it can't afford to leak, or protecting intellectual property that competitors would exploit instantly if it surfaced early, needs a formal way to say that certain stakeholders, even senior ones, are intentionally kept out of a specific decision until it's safe to bring them in.

Need-to-Know Portfolios

Apple is widely known for running product development on a strict need-to-know basis. Teams working on one component of an unreleased device are often kept from seeing how their piece fits into the whole, and even internal groups can be unaware that a related project exists until close to launch. This isn't dysfunction. It's a deliberate choice, since a single leak ahead of a major announcement can cost the company both competitive advantage and the surprise that drives its marketing.

A company like Rambus, which licenses semiconductor technology and patents, faces a related but distinct pressure. Its value depends heavily on protecting proprietary technical designs before they're patented or licensed, since premature disclosure can undermine both patent protection and licensing negotiations. In a portfolio environment like this, a CAIRO-style chart, with an explicit Omitted column, gives a portfolio manager a formal, defensible way to document who was deliberately kept out of a sensitive decision, rather than leaving that exclusion undocumented and open to later questions about favoritism or unfair treatment.

The Omitted role does something else that matters beyond secrecy itself. It protects the people who are excluded, not just the information. Without a documented Omitted category, someone left out of a decision has no way to know whether that exclusion was deliberate policy or an accident, an oversight, or a sign they've fallen out of favor. Naming the exclusion explicitly turns an ambiguous, potentially damaging silence into a clear, defensible governance choice.

Myth

It's tempting to assume that more transparency is always better, and that deliberately excluding stakeholders from a decision always signals something is being handled badly. In highly confidential work, the opposite can be true. A portfolio manager who insists on full RACI-style openness for a project that genuinely requires secrecy isn't being more transparent. They're increasing the risk of a leak that could cost the company far more than the goodwill gained from including everyone. CAIRO exists precisely because some portfolios need a formal, honest way to say that exclusion is the responsible choice, not a shortcut around governance.

CAIRO isn't a replacement for RACI in most portfolios. It's a specialized tool for the specific situations where confidentiality itself has to be governed as carefully as the work it's protecting.