Boards have been shown federal revenue forecasts before, and they have watched most of them miss. The pattern is familiar enough that a well-built plan gets discounted alongside a badly built one: a large addressable market number, a pipeline of unqualified conversations, a hockey stick beginning in the second half, and a set of assumptions nobody can inspect. The board's skepticism is earned, and the way through it is not more confidence. It is a plan built from evidence the board can check themselves, with the cost of entry stated honestly, timing that respects how federal money actually moves, and a delivery capability that can be demonstrated rather than described.
This is written for the chief executive or chief financial officer who has to stand in front of a board and defend a federal growth line. What follows is what a credible plan contains, where the numbers come from, and the specific things boards ask that unprepared plans cannot answer.
Why federal forecasts miss
Five causes account for most of it, and only one of them is about the market.
The market number is not a pipeline. A total addressable market derived from category spending tells you the size of a pond, not whether you have a boat. Boards have learned to ignore it, and including it prominently signals that the rest of the plan may be similar.
Pipeline stages describe your process, not the buyer's. A federal opportunity does not advance because your sales team had a good meeting. It advances when a specific procurement event happens: a requirement is written, funding is identified, a market survey goes out, a solicitation is issued, evaluation completes, award is made. A pipeline whose stages are not tied to those events cannot be forecast.
The cost of entry is missing or understated. Security work, accessibility work, a deployment model that works in a government environment, documentation, and a sales function that understands the buyer. These are real and they are usually left out, so the plan shows revenue arriving before the spending that makes it possible.
Timing ignores the fiscal calendar. Federal money is appropriated and expires on a schedule that has nothing to do with your quarters. Plans that spread revenue evenly across the year are wrong before they start.
There is no delivery capability behind the plan. The most common and least discussed. The plan describes winning work. It does not describe who deploys the product into the agency environment, who carries it through security review, who supports it in production. A board that has seen a federal award turn into an eighteen-month delivery problem asks about this first.
What makes a federal plan credible to a board, weighted by how hard it is to fake
Editorial weighting, illustrative rather than measured. The last row is deliberately low: a market size number is the easiest thing in the deck to produce and the least informative.
Build the spend picture from the public record, and show the method
Federal contract awards and federal spending are published. That is the single most useful fact for this exercise, because it means your market sizing can be built from records the board can open themselves rather than from an analyst estimate you paid for.
The method matters more than the number, and the method is what you present. It runs roughly like this. Identify the product or service categories that correspond to what you sell, using the classification codes the government itself applies to awards. Pull the awards in those categories over several recent years. Filter to the agencies whose mission plausibly needs your product. Separate recurring spend from one-time spend, because a large one-time award tells you little about next year. Look at who won, at what values, and on what kind of instrument. Then narrow to the subset that is genuinely addressable: awards where a product like yours was the substance of the work rather than an incidental component.
What emerges is not a market size. It is a list of named buying offices with a demonstrated pattern of spending on things like yours, and that is a far stronger artifact. A board can pick any row and ask you about it. Being able to answer is what separates a plan from a projection.
Two cautions to state in the room before someone else does. Published award data lags, and the classification codes are applied imperfectly, so any single row may be miscategorized. Say so, describe how you handled it, and the rest of your numbers become more believable rather than less. And spending history is evidence of a pattern, not a commitment to repeat it: appropriations change, programs end, and priorities shift with administrations.
A pipeline the board can test
Replace stages named after your sales process with stages named after events that happen in the buyer's world and leave a trace. Each stage should have an objective entry criterion, so that anyone can audit whether an opportunity belongs there.
| Stage | Objective entry criterion | What the board can verify | What to report |
|---|---|---|---|
| Identified need | A named office with a documented requirement or a stated problem | The office, the program, the person | Count only; no value |
| Funding visible | Budget identified, or prior-year spending in the same category | The public record showing the pattern | Count and an unweighted range |
| Market activity | A published notice, market survey or industry engagement | The notice itself, with its date | Value with a low probability weight |
| Solicitation issued | A live solicitation with a due date we intend to answer | The document and the due date | Weighted value and a decision date |
| Submitted, awaiting evaluation | Response delivered, evaluation period running | Submission confirmation and stated timeline | Weighted value and an expected decision window |
| Awarded, in delivery | Award received, period of performance running | The award record and the delivery plan | Recognized revenue by period |
Two rules make this pipeline useful rather than decorative. First, nothing carries a value until funding is visible, because a value attached to an unfunded need is the specific thing boards have learned to discount. Second, every opportunity past the third stage carries a date, and you report against those dates at the next meeting. A pipeline that is never scored against its own dates teaches the board nothing, and a pipeline that is scored honestly, including the misses, buys you credibility that no amount of growth in the total can.
State the cost of entry before the revenue
The fastest way to lose a board on this topic is to show revenue in the first year with no visible spending in front of it. The strongest version of the plan puts the cost of entry first, itemized, with the reasoning attached. There are four categories.
Product engineering. Making the product deployable into an environment you do not control, identity behind an interface, an audit trail with retention, every outbound dependency enumerated, accessibility remediation with real testing, and the documentation set buyers read. This is mostly one-time per product and it is reused by every subsequent buyer, which is the point to make when someone asks why it costs what it costs.
Security and authorization. If your deployment model requires a formal authorization, it is a program with its own engineering, its own assessment cost and a permanent monitoring obligation afterward. If it does not, buyers still run security reviews and you still need the artifacts.
Go to market. People who understand federal buying, the time to build relationships with program offices, and the contract instruments needed to transact. This is slower to produce results than commercial sales hiring, and the plan should say so.
Delivery capacity. Who actually deploys and operates the system after an award. Boards ask this and unprepared plans answer with a hiring line that has not started.
Size the first two by running a gap assessment against your product and converting each gap into an engineering estimate in hours, by the team that would do the work. That produces a number your finance function can defend line by line, and it produces the ranked build list that becomes the operating plan.
Questions a board asks that unprepared federal plans cannot answer
Editorial weighting, illustrative rather than measured. The last row is deliberately low: it is the question boards ask when they have stopped believing the rest.
Timing that respects how the money moves
Federal purchasing is shaped by appropriation cycles, and the plan should show it. Some funds must be used within the fiscal year and some remain available longer, which produces uneven buying activity through the year and a concentration of awards near the end of the fiscal year for funds that would otherwise expire. Continuing resolutions, when they occur, slow new starts while allowing existing work to continue. None of this is a secret and all of it is checkable, so building it into the shape of the forecast reads as competence rather than as excuse-making.
Three practical consequences for the plan. Do not spread revenue evenly across quarters. Show the lag between award and revenue recognition, which for a deployment requiring security review can be substantial. And show at least one downside case: what the plan looks like if the first award slips two quarters. Boards trust a plan with a stated downside far more than one presented as a single line, because the downside case proves you understand the mechanism rather than the hope.
The delivery capability is the part they will test
The strongest sentence in a federal plan is not about the pipeline. It is a demonstrable answer to "who builds and runs this inside the agency." Boards test it, because a federal award that cannot be delivered is worse than no award: it consumes the reference you were trying to create.
Three answers are credible. You have engineers who have done it, and you can name the systems and what they did. You are hiring them, with a specific plan, funded, and started. Or you have an engineering partner that has built and deployed inside agencies, engaged under contract, with named people and a defined scope. The one answer that is not credible is a hiring line item that has not begun.
Whichever answer you give, make it inspectable. A board member should be able to ask what the deployment environment is, who wrote the security documentation, what the accessibility position is, and who is called when the system fails at two in the morning, and get specific answers in the room.
How to present it
- Lead with the buying offices, not the market size. A short list of named offices with a demonstrated spending pattern, drawn from the public record, with your method stated in one paragraph.
- Show the pipeline by stage with objective criteria, values only from the funding-visible stage onward, and a date on everything past market activity.
- Put the cost of entry before the revenue, itemized across product engineering, security, go to market and delivery capacity, sized from an engineering estimate rather than a percentage.
- Show the fiscal shape, including the lag between award and recognition, and one downside case with the first award slipping two quarters.
- Answer the delivery question explicitly, naming who builds and operates the system, and make it inspectable.
- Score last quarter's plan against what happened, including the misses, before presenting the new one. Nothing else builds credibility as fast.
- State the assumptions on one page, so that when something changes you can point at which assumption moved rather than restating the whole plan.
How we work with companies building this plan
We are an engineering firm. We build AI systems, data platforms, cloud infrastructure and full-stack software, and we build and deploy them inside federal agencies under the security, accessibility and operational constraints these plans depend on. That is why we are useful at this stage: the two weakest parts of most board-facing federal plans are the cost of entry and the delivery capability, and both are engineering questions.
In the first two weeks we deliver two documents. A readiness assessment, written as engineering work rather than as findings: every gap between your product today and a product that can deploy and survive review in an agency environment, expressed as a specific change to a specific component, with an hours estimate and a dependency order. And a spend and pipeline method document showing how the categories were derived from the public record, which agencies and offices they point to, and where the data is weak, so the board can check any row.
Together those give the plan the two things it usually lacks: a defensible cost of entry built from engineering estimates rather than a percentage, and a delivery answer that a board member can interrogate.
Then, if you want it, we build. Our engineers work in your repositories, on your branching model, through your review process: deployment automation, identity and audit seams, accessibility remediation, security documentation written from the system as built, and integration into the agency environment. We sit in the buyer's technical review alongside your team.
What you keep. Everything. The code is yours, in your repositories, under a written present assignment of intellectual property. The analysis, the documentation and the security artifacts are yours, and they carry forward to every future buyer. The customer relationship is yours; we do not sell your product and we do not stand between you and the agency. The handover is a rehearsal in which your team deploys and operates while we watch.
How it is priced. Fixed-price milestones where scope is definable, which fits the readiness assessment, the spend analysis and the documentation set. A committed team at a monthly rate where the work is a continuous build. Most programs use both.
How it starts. One email with a one-page brief: what the product does, which agencies you believe are buyers, what deployment model has been discussed, when the board meets, and the date that matters. We return a scoped, priced statement of work with the assumptions written down.
Bottom line
A board does not disbelieve federal revenue. It disbelieves federal revenue plans, because it has seen several that were built from a market size, a pipeline of conversations and an unexamined assumption that delivery would take care of itself. The plan that survives is built the other way around: named buying offices drawn from records the board can open, pipeline stages tied to procurement events with dates attached, the cost of entry itemized and sized from engineering estimates before any revenue appears, timing that reflects the fiscal calendar, a stated downside case, and a delivery capability that can be inspected in the room. Present last quarter's plan against what actually happened before you present the new one. Credibility compounds faster than the pipeline does, and it is the thing that gets the next tranche funded.
Frequently asked questions
Start from the public record rather than a market size estimate. Identify the categories that match what you sell using the classification codes the government applies to awards, pull recent awards in those categories, filter to agencies whose mission needs your product, separate recurring from one-time spend, and narrow to awards where something like your product was the substance of the work. What you present is a list of named buying offices with a demonstrated pattern, plus the method used to derive it, so any row can be checked.
Five reasons, only one of which is the market. The market size number is presented as if it were a pipeline. Pipeline stages describe the seller's process rather than procurement events that leave a trace. The cost of entry, meaning security work, accessibility, deployment engineering and documentation, is understated or missing. Timing ignores the fiscal calendar and spreads revenue evenly. And there is no inspectable answer to who deploys and operates the system inside the agency after an award.
Stages tied to events in the buyer's world with objective entry criteria: an identified need at a named office, funding visible, market activity such as a published notice or survey, a live solicitation you intend to answer, a submitted response awaiting evaluation, and an award in delivery. Attach no value until funding is visible, and attach a date to everything past market activity. Then report against those dates at the next meeting, including the misses, because a pipeline never scored against itself teaches a board nothing.
Four categories. Product engineering to make the software deployable into an environment you do not control, with identity behind an interface, an audit trail, enumerated dependencies, accessibility work and a documentation set. Security and authorization work, which may be a full program with a permanent monitoring obligation. Go to market, meaning people who understand federal buying and the instruments to transact. And delivery capacity for after the award. Size the first two by converting a gap assessment into engineering hours rather than applying a percentage.
Who deploys and supports the system inside the agency after you win. Which named offices have bought something similar before, and how you know. What you said last quarter and what actually happened. What you spend before any revenue arrives, and on what. And what the plan looks like if the first award slips two quarters. A plan that answers those five in the room, with specifics, gets funded. A plan that answers with a market size is usually being asked that question because the board has stopped believing the rest.