There’s a moment in nearly every capital review that tells you whether the asset-management program is mature. A facilities VP presents the requested capital plan. A board member, or a council member, or a deputy administrator asks a direct question: “What happens if we don’t fund this?” The next thirty seconds decide whether the program gets the money.
Mature programs answer in the language the decision-maker uses: risk, consequence, tradeoff, recommendation. Less-mature programs answer in the engineering team’s language: condition scores, criticality indices, remaining useful life. Both answers might be correct. Only the first one lands with the board.
What boards ask about
Across hundreds of capital reviews, the questions decision-makers ask hardly change. They don’t change much across federal, state, municipal, healthcare, or industrial settings. Roughly in order of frequency:
- What happens if we don’t fund this? The consequence question. They want to know the worst case, in their language.
- Why this year, why this much? The timing question. They want to know what changes if it slips a year, or two, or five.
- What would you cut if you had to cut something? The tradeoff question. They want to know you’ve thought about priority and didn’t just add up the total need.
- What if we’re wrong about this? The risk question. They want to know what the downside is if the data turned out to be off.
Notice what’s missing. Nobody asks about your condition assessment methodology, your criticality scoring, or which version of ISO 55000 you align to. Those are your tools. They belong upstream of the conversation.
The translation problem
Asset-management programs usually struggle in front of boards because nobody translated the data. The data was built to support engineering decisions. The audience is making financial and political decisions. The same fact has to be said differently for each, and that’s your job as the program leader.
If the only way to defend the recommendation is to walk the board through the criticality model, the recommendation hasn’t been translated yet. It’s still in engineer-speak.
The most common mistake I see is carrying the engineering reports straight into the boardroom. A condition rating of 3.2 means something specific to your reliability engineer. To the board, it’s a number without context. Translating it (“this asset is past the threshold where we typically see failure rates accelerate”) takes one extra sentence and changes the conversation.
A simple structure for capital narratives
The structure that works has four parts, in this order:
Risk
What is the asset, what condition is it in, and what’s the probability of failure within the planning horizon? Numbers are fine here but don’t lead with them. Lead with a sentence a non-engineer can follow.
Consequence
What happens if it fails? Connect it to something the board cares about: mission, safety, cost, or reputation. The strongest capital cases name the consequence in the audience’s own terms.
Tradeoff
What are the alternatives, and why is this the right one? Even when the answer is “there’s no real alternative,” say so out loud. It builds trust. The board wants to know you looked at the options before you picked one.
Recommendation
Tell them in one sentence exactly what you want approved. Don’t bury it!
The examples that work, and the ones that don’t
What works has three things going for it. It’s honest about confidence, it uses the audience’s language for consequence, and it has one clear recommendation. What fails usually misses on at least one of those.
Three patterns that work:
- Walking through the decision logic. “We considered X. We chose Y. Here’s why.” Even when boards disagree with the conclusion, they trust the process.
- Stating uncertainty directly. “Our highest-confidence call is the chiller. The next three on the list are our best read given current data, and we’ve flagged where we’d want better assessment.” Honest confidence levels work in your favor.
- Naming what the recommendation buys. Beyond the asset replacement, name the mission continuity, the patient care, the regulatory standing. Connect the line item to the outcome the board cares about.
Three patterns that fail:
- Leading with the methodology. Boards don’t need to learn ISO 55000 to evaluate your request. If your defense relies on educating them, the case isn’t built yet.
- Presenting a long list with no priority. If the board can’t tell what the top three asks are, they can’t approve them. Force-rank before you walk in.
- Hiding the uncertainty. Boards have long memories. Present a number with confidence, have it turn out to be off, and you will pay for it in trust for the next decade.
Prep before your next board meeting
Two things to do the week before your next capital review:
- Run your top three asks through the four-part structure. Write them out. Risk, consequence, tradeoff, recommendation. If any of the four are weak, fix them before you walk in.
- Anticipate the “what if we don’t fund this” question for each. Have a one-sentence answer ready for every line item. The board will ask. You better have a specific answer, in their terms.
The capital plan and the data don’t change. What changes is whether you’ve done the translation work before you get to the room. Mature programs do that work, and their funding shows it. So what will you say when a board member asks what happens if they don’t fund it? Would a non-engineer understand your answer?
