What Governing a Multi-Billion-Dollar Portfolio Teaches You About Saying No

Disciplined portfolio leaders spend as much effort declining good ideas as approving great ones.

At NASA, I worked where enterprise architecture, strategy, and modernization met a digital portfolio worth more than $2.7 billion. What shaped the work most was what that portfolio supported: national space and science missions. The work had to account for:

• Complex technical environments;

• Strict cybersecurity and regulatory requirements;

• Aging systems;

• Planning horizons measured in years.

  
  

Mistakes in that setting were expensive. Still, an organization built around exploration can never avoid risk altogether. The job was to understand which risks were necessary, who had authority to accept them, and what evidence had to exist before anyone committed.

Over time, I came to see saying no as the most important skill in that work, more important even than managing the budget.

One example was NASA’s Web Modernization effort. With more than 3,500 web applications in the portfolio, the answer could not be to modernize every one of them; we had to challenge which applications still justified their existence, consolidate overlapping capabilities, and retire those that did not. Saying no in that case protected scarce modernization resources from being spent recreating yesterday’s complexity on newer technology.

A portfolio is a system of commitments

Many organizations manage their portfolio as a list of projects with budgets and status colors. That view hides much of what each project actually spends.

A funded initiative draws on:

• Leadership attention;

• Technical talent;

• Procurement time;

• Data resources;

• The workforce's capacity to absorb change.

  
  

It also creates dependencies. A new platform may need identity integration, a security review, data migration, training, and the retirement of an older system. A project that looks self-contained can create obligations across much of the enterprise.

Make too many of these promises, and the money isn't the only thing that gets spread thin. Accountability, attention, and the organization's ability to change are stretched along with it. Eventually every initiative carries the "priority" label, and the label stops meaning much.

Why capable organizations struggle to say no

Weak portfolio decisions rarely begin with bad ideas. More often they begin with good ideas backed by credible sponsors, polished presentations, and real problems.

A project can be worthwhile on its own terms and still be wrong for the portfolio. It may duplicate an existing capability, depend on data or skills the organization lacks, or simply arrive too early. Declining it can also feel like rejecting the people who spent months building the case.

Good governance therefore treats two questions separately: whether an idea has merit, and whether to fund it now. When leaders decline a proposal, they are usually saying something more specific:

• Not yet.

• Not at this scale.

• Not without stronger evidence.

• Not until a dependency is resolved.

• Not as a separate platform.

• Not unless something else stops.

  
  

Each of these leads somewhere different, so leaders should say which one they mean.

Lesson 1: A strategy has to rule things out

If a strategy can justify every proposal, it provides no guidance. Nearly any investment can be linked to modernization, innovation, or AI.

Leaders need sharper questions:

• Which specific outcome does this advance?

• What measurable change should follow?

• What will we stop or postpone to make room for it?

• 
  

The last question gets skipped most often, and it's the one that makes strategy real. When approving an initiative doesn't require naming what it displaces, the decision is being made without seeing the whole portfolio.

Lesson 2: Having the money is only part of it

An organization can afford a project and still lack the people, architecture, data maturity, or appetite for change to deliver it.

This is how portfolios become overloaded even though each business case looks sound on paper. Every proposal assumes access to the same security reviewers, data owners, architects, and change leaders, and ten other proposals assume the same people. The plan balances financially and falls apart in execution.

Sometimes the best way to protect a valuable initiative is to hold it back until the organization can support it.

Lesson 3: What helps one division can cost the enterprise

A division may want a faster, purpose-built solution for a need that is entirely real. The enterprise, though, inherits everything that comes after launch:

• Duplicated capability;

• New integrations;

• Added security and data obligations;

• Running costs once the project team moves on;

• Eventually, the work of retiring the system.

  
  

Portfolio governance exists partly to make decisions no single project can make for itself. Sometimes that means choosing a shared capability that the requesting team finds less satisfying.

A good example came from process automation across NASA’s mission-support organizations. Rather than let each organization solve its workflow needs with another purpose-built application, we increasingly looked to extend Microsoft Power Platform as an enterprise service, giving teams room to solve local problems without creating another system for the agency to secure, integrate, fund, and eventually retire. The local solution might have been faster to approve; the enterprise solution was cheaper to live with.

Lesson 4: Match the evidence to the consequence

Scrutiny should scale with what's at stake. Putting a small, reversible experiment through the same review as an enterprise platform smothers learning. Waving a long-lived, hard-to-reverse commitment through as an experiment invites expensive surprises.

Evidence requirements should rise with three things: the size and duration of the commitment, how hard it would be to undo, and how sensitive the areas it affects are.

AI makes this especially relevant. An internal productivity pilot and a model that influences eligibility, safety, or resource allocation call for very different levels of governance, even when the underlying technology looks alike.

Certainty is rarely available, so the commitment itself should be shaped around what's unknown. Leaders can:

• Fund discovery before implementation;

• Test the riskiest assumption first;

• Release money in stages tied to evidence;

• Avoid contracts or architectures that lock the organization in early.

  
  

Structured that way, approval becomes a series of governed steps. Leaders can back the next sensible move without betting on an outcome the evidence can't yet support.

Lesson 5: Set stopping conditions at the start

Funded projects quickly gather supporters. Teams form, contracts get signed, and leaders become publicly associated with success. All of that makes stopping harder, even after the original assumptions have failed.

The time to agree on continuation criteria is before any of that happens. Leaders should settle:

• What has to be true for the work to continue;

• When those assumptions will be tested;

• What evidence would prompt a pause or change of direction;

• Who has the authority to make that call.

  
  

Portfolios without stopping rules slowly fill with initiatives too established to question and too weak to succeed. Shutting one down is governance working as intended. The real failure is letting it run on because nobody wants to own the decision.

Make the reasoning visible

A sound decision can still erode trust when people can't follow how it was made. Sponsors should be able to see:

• Which criteria applied;

• What evidence was missing;

• Which tradeoff settled the matter;

• What would have to change for the proposal to come back.

Leaders don't have to publish every deliberation, but they do need to be consistent and traceable. Once people understand the process, a declined proposal feels less like a personal verdict and more like stewardship of shared resources.

Before you approve the next investment

Ask the following questions:

1. Which strategic outcome does this advance?

2. What evidence shows this intervention will produce that outcome?

3. What existing capability or project overlaps with it?

4. Can the organization actually implement and absorb the change?

5. What dependencies must be resolved first?

6. What will we delay, reduce, or stop if we approve it?

7. What would cause us to change course?

   
   

Saying no as leadership

Approving too much makes the current meeting easier and hands the consequences to delivery teams. Those teams then face competing priorities, fragmented architecture, exhausted staff, and initiatives that stay alive without the support they need to succeed.

A disciplined no keeps high-value work from being crowded out and spares teams from impossible demands. It also protects mission, customer, and shareholder resources from commitments nobody can properly back.

For an organization where being wrong is costly, the willingness to say no is one of the clearest signs that its leaders take responsibility seriously.

Yasser Haridi is CEO and Co-Founder of BIITLAB, where he and his partners advise leaders on enterprise strategy, portfolio governance, and AI adoption. He is a former NASA Chief Enterprise Architect.