Yolanda Ferreira-Okafor pulled up the slide deck at 7:42 on a Tuesday morning, fourteen minutes before her briefing to the Secretary. She was eighteen months into her tenure as Chief Information Officer (CIO) of the U.S. Department of Labor's Employment and Training Administration (ETA), and she had a problem: the agency's AI strategy document, approved the previous spring, was already obsolete. The Deputy Secretary who championed it had resigned. The $6.2 million IT Modernization Fund allocation tied to it was under continuing resolution freeze. And two of the three vendors short-listed in the preliminary market survey had pivoted away from public-sector work entirely. Yolanda's slide deck still said "Year One: Pilot." The calendar said Month Eighteen.

This lesson is about building AI roadmaps that do not collapse the moment reality diverges from the plan, which it always does in government. Not because government is incompetent, but because government operates inside constraints that private-sector roadmaps were never designed to survive: biennial budgets, multi-year procurement cycles, leadership that turns over on a political clock rather than a project clock, and a public accountability standard that punishes visible failure more harshly than invisible inaction.

Strategy Says What; a Roadmap Says How

A strategy says "we will do X." A roadmap says here is how, here is when, here is what it costs, and here is what could stop us. That difference does real work. Building the roadmap forces you to think through sequencing and dependencies, asking what has to happen before what. It establishes explicit resource requirements: how many people, with what skills, on what budget. It creates accountability, because you have committed to specific milestones by specific dates. And it enables course correction, because when reality diverges from the plan you can see exactly where and adjust rather than discovering the divergence at the end.

This is where many organizations fail. They produce a beautiful strategy document and then try to do everything in it at once. Resources spread thin, nothing gets done well, and eighteen months later nothing has shipped and the momentum is gone. The remedy is sequencing: breaking an ambitious multi-year vision into phases that each have clear milestones, explicit resource requirements, and realistic timelines. The question is not what could we do, it is what is the sequence that builds capability progressively and de-risks the next step.

Government roadmaps are harder to build than private-sector ones for four structural reasons. Budgets are uncertain, because appropriations are decided elsewhere and may not fund what you planned. Personnel are uncertain, because hiring freezes happen and people leave. Dependencies are complex, because your AI project relies on IT infrastructure, data governance, and compliance processes you do not fully control. And political priorities shift, so what is supported today may be deprioritized after an administration changes. The roadmap has to be flexible enough to absorb all of that while remaining clear enough to actually direct work.

Think in Structures, Not Sprints

The controlling analogy for a government AI roadmap is not a product sprint. It is a suspension bridge. A suspension bridge is built from both ends toward the middle. The towers go up first: load-bearing, non-negotiable, expensive. The cables come next, tensioning across the span. Only then do you lay the roadway. You cannot pour the roadway before the cables exist, and you cannot string the cables before the towers are anchored. The sequence is not a preference. It is physics.

AI strategy in government works the same way. Data infrastructure is the tower. Governance is the cable. Deployed models are the roadway. You cannot deploy responsibly before governing, you cannot govern what you cannot see, and you cannot see anything if your data sits in seventeen incompatible legacy systems across four program offices, which at ETA it did. The roadmap that ends a career is rarely the one that moved too slowly. It is the one that poured roadway before the towers were built, and then collapsed publicly, in front of Congress, with claimants' data exposed.

Dependencies Are Your Longest Lead Items

Before sequencing anything, identify what has to happen first. Most government AI roadmaps fail because they underestimate dependencies, and dependencies do not go away when you promise to handle them in parallel. Five categories cover almost all of it, and each carries a lead time that dwarfs the AI work itself.

Data dependencies come first: do you have clean, accessible, governed data? If not, expect 12 to 18 months of data work before a serious AI project is possible. Governance dependencies ask whether you have decision-making processes for approving AI projects, risk review, and fairness assessment; if not, budget 6 to 12 months of governance building. Infrastructure dependencies cover cloud platforms, data warehousing, and model deployment capability, at 9 to 18 months if you are starting without them. Organizational capacity, meaning people with the right skills whom you can hire or develop, runs 6 to 24 months depending on where you start. Compliance dependencies, meaning understanding the federal regulations, state law, executive orders, and policy directives that apply and integrating them into your processes, run 6 to 12 months.

Those ranges are why the sequencing rules below are not stylistic. Data before models: you cannot train or evaluate a model on data you do not understand. At ETA, the fraud detection scope had to narrow from 12 claim types to 4 because the data for the other 8 was inconsistently structured across state reporting systems. Discovering that during model development rather than during data assessment would have cost an estimated $400,000 in rework and four months of delay. The data readiness assessment is not optional pre-work. It is the project.

Governance before deployment. Deploying an AI model before you have a governance structure is not agile, it is liability: disparate impact claims under Title VI, due process challenges when automated decisions affect benefits, and Inspector General audit findings that follow you into your next role. Governance before deployment means defined human review thresholds, model documentation standards, and an appeals pathway for affected individuals. None of this requires a large team, but the review threshold only protects anyone if the reviewer has the time and the authority to overturn the system's output. A review step nobody can fail is documentation, not governance.

Contracts before commitments. Never announce a deployment date before the contract is signed. Federal procurement for a technology contract above the simplified acquisition threshold, which is $250,000, takes an average of 12 to 18 months from requirements finalization to contract award, and state procurement timelines vary from 6 to 30 months. Yolanda's Year Two expansion relied on a vendor already under an existing Blanket Purchase Agreement (BPA) held through a General Services Administration (GSA) schedule contract. That single procurement choice saved an estimated 11 months. It was not luck. It was designed in Year One, when the team deliberately scoped the pilot vendor to an existing contract vehicle.

Phasing the Roadmap

Most successful government AI roadmaps run in three distinct phases, and the phases are about capability rather than about calendar years.

Phase 1, Foundation, typically 12 to 18 months. The focus is building the foundation so that serious AI work becomes possible: complete the data inventory and governance work, establish AI governance structures and processes, build or acquire basic technical infrastructure such as cloud platforms and data warehousing, hire or train initial data and AI talent, identify one or two high-value pilot use cases, and build basic change management and training capacity. The output is not a model. It is an organization capable of running serious AI projects.

Phase 2, Pilots and Learning, typically 12 to 18 months. Launch one or two major pilots, capture detailed learning about what worked and what you would do differently, expand data governance to handle additional sources, expand technical talent, build change management for the staff the pilots affect, and develop the metrics and monitoring systems you will need at scale. The output is working systems that demonstrate value, proven capability, and organizational learning you can point to.

Phase 3, Scaling, typically 12 to 36 months. Deploy the successful pilots to production, launch a second wave of projects, scale the data infrastructure to support concurrent work, scale the technical and governance teams, integrate AI into regular organizational processes, and build continuous improvement mechanisms. The output is multiple working systems delivering value across the organization rather than one impressive system in one office.

One discipline holds the phases together: a phase label is something you claim about your own readiness, not a status anyone grants you. Declaring Phase 2 because the calendar says Year Two, while the Phase 1 data inventory is still open, does not move the organization into Phase 2. It removes the gate. Say which Phase 1 outputs exist before you use the label in a briefing, because the label will be quoted back to you long after the caveats are forgotten.

Phasing for Budget Cycles: The ETA Case

A three-year roadmap in government needs to function as three one-year roadmaps that connect coherently, rather than as a single arc that assumes continuity. Continuity is precisely the thing you cannot assume, which is why the phase boundaries at ETA were pulled onto the budget calendar.

Year One was not about AI. It was about earning the right to deploy AI, through three things: a data inventory, governance scaffolding, and a single pilot producing defensible numbers. Concretely: a data readiness assessment across the Unemployment Insurance (UI) and Job Corps offices, six weeks with two contractors at $180,000 from the existing IT operations budget; an AI Governance Board with representation from program, legal, privacy, civil rights, and IT, carrying zero new budget authority and meeting monthly; and one bounded pilot, AI-assisted fraud detection on UI initial claims, scoped to three states with a 90-day evaluation window and a success threshold registered in advance, so that changing the standard afterward requires someone to visibly change it rather than quietly reinterpret it. Year One deliverables must be completable inside existing appropriations. If you need new budget authority to begin, you have already added a 12 to 24 month delay.

Year Two assumes the pilot succeeded and carries a contingency branch for the case where it did not, because a roadmap with no failure branch is a wish list. If the pilot succeeded, Year Two uses that evidence to secure new appropriations in the budget cycle that was running concurrently with Year One. That concurrency is the design, not a coincidence: the pilot's 90-day evaluation window has to close before the agency budget request deadline. At the federal level that means the President's Budget Request submission to the Office of Management and Budget (OMB) in September. At the state level it means the Governor's budget request, typically due 90 to 120 days before session opens. ETA's Year Two investments were a unified data lake for UI program data at $2.1 million from the IT Modernization Fund, a vendor-neutral AI evaluation framework built in-house at 1.5 FTE for eight months, and expansion of the fraud detection model to all 50 states plus territories.

Year Three is where the roadway gets poured, but only if the towers and cables are actually in place rather than merely on a slide. Yolanda's test before any Year Three deployment was whether a new CIO arriving tomorrow could understand what was built, why it was built that way, and how to operate it without her. If the answer was no, it was not ready to institutionalize. Year Three also has to embed AI operations in the agency's base budget, not as a special initiative but as a recurring line in the IT operations appropriation. Special initiatives end. Base budget lines survive transitions.

Milestones and Decision Gates

Each phase needs milestones that function as accountability checkpoints rather than as decoration. A representative Phase 1 sequence runs: by month 3, data inventory complete, governance board established, initial hiring underway; by month 6, data governance policy approved, technical infrastructure procured, initial staff in place; by month 9, pilot use cases selected, project teams formed, data work underway; by month 12, first data deliverables ready, governance processes tested, pilot development underway; and by months 15 to 18, first pilots approaching completion and the organization ready for Phase 2.

Phase 2 follows the same shape at a different altitude: first pilot systems operational by months 6 to 9, business case benefits being validated and the organization actually using the pilot systems by months 9 to 12, organizational learning captured and second-wave projects approved by months 12 to 15, and readiness for Phase 3 scaling by months 15 to 18. Notice that "the organization is using the system" is a separate milestone from "the system is operational." Those two dates are further apart than anyone expects, and collapsing them is one of the more common ways a roadmap becomes fiction.

At the end of each phase, hold a decision gate rather than a transition. Explicitly ask what you learned, whether you are ready to move forward, and whether the roadmap needs adjusting. Do not move to Phase 2 until Phase 1 is genuinely complete. The temptation is to commit to a three-year plan and execute it blindly, moving to the next phase automatically even when the last one did not work as expected, which means you are following a plan that was reasonable eighteen months ago and has not been tested against anything you have learned since.

Milestones That Survive Transitions

Leadership turnover is not a risk to be managed around. It is a certainty to be designed for, and a multi-year roadmap will in the ordinary case outlast the leader who commissioned it. Three techniques anchor milestones to institutions rather than to individuals.

1. Embed milestones in budget justifications. Appropriations language creates commitments that outlast any individual. Yolanda's Year Two funding came with a conference report directive requiring a progress report to the Appropriations Committee by March 1. That directive survived three acting secretaries.
2. Use cross-agency dependencies as anchors. ETA's fraud detection expansion required data-sharing agreements with SSA and IRS. Those interagency agreements created institutional momentum that no single new appointee could easily reverse.
3. Build the transition brief into every milestone. A one-page document for an incoming executive covering what was decided, what was built, what it costs to maintain, and what happens if it is stopped. Yolanda called it the hit-by-a-bus brief, and it existed for every major milestone before that milestone closed.

Resourcing the Roadmap Honestly

Most government agencies underestimate what a roadmap costs, and the underestimate is concentrated in two places: operations after go-live, and the people who hold institutional memory. A typical Phase 1 team is a program manager at 1.0 FTE, a data architect at 1.0 FTE, one to two data engineers, a data scientist at 0.5 to 1.0 FTE, a governance and compliance person at 0.5 to 1.0 FTE, and change management at 0.5 FTE. The corresponding budget runs personnel at $500K to $800K, data infrastructure at $500K to $1M, tools and platforms at $200K to $500K, contractors and consulting at $500K to $1M, and training and change management at $200K, which the source totals to a rounded Phase 1 range of $2 million to $3.5 million.

That sounds large until you set it against what it buys: a foundation that enables years of AI capability rather than one system. Agencies routinely spend comparable sums accidentally, in failed projects that failed because nobody funded the foundation first. The counterargument that the agency cannot afford Phase 1 usually turns out to be a claim that the agency would rather spend the money in smaller, less visible increments on projects that will not work.

Proportionally, a rough allocation for a $5 million three-year initiative in a mid-sized federal program office puts Year One at 60 percent infrastructure and assessment, 25 percent pilot development and evaluation, and 15 percent governance and training, totalling $800,000 to $1.2 million and drawing mostly on existing authority. Years Two and Three go 40 percent technology build and integration, 30 percent ongoing operations and maintenance, 20 percent staff training and change management, and 10 percent evaluation and audit readiness, totalling $3.5 to $4.5 million and requiring new appropriations.

After Year Three, budget 18 to 22 percent of total implementation cost annually for operations, maintenance, and model retraining. If your budget submission does not include that number, a future budget office will find the line and cut it, and the system will degrade quietly rather than fail loudly, which is worse. Plan for at least 1 FTE dedicated to AI program management per major initiative plus 0.5 FTE for data governance, regardless of how much vendor support you have. Those are not overhead. They are the institutional memory that survives a contract transition.

Contingency and Buffers

Your roadmap will change. Budgets get cut, priorities shift, technology moves. A good roadmap anticipates this rather than treating each divergence as an exception. Build in time buffers: if you think Phase 1 takes 12 months, plan for 15 to 18, so that hitting 12 puts you ahead rather than merely on time. Build in resource buffers: if you think you need 4 data engineers, plan for 4.5 to 5, because people leave and hiring takes longer than expected. And reserve 10 to 15 percent of the budget as contingency for unexpected costs, which on a $2 million estimate means budgeting around $2.3 million.

The reason to do this is credibility rather than comfort. When you estimate with no buffer and reality diverges, which it always does, you miss deadlines and budgets immediately and stay behind for the rest of the program. Everyone concludes you cannot estimate. When you buffer and then land on your original estimate, you are early and under budget, and the next request you make gets believed. In an environment where your funding depends on committees who have watched other technology programs overrun, that accumulated credibility is a resource in its own right.

Two Worked Roadmaps

A federal agency of 5,000 employees with scattered AI interests wanted an enterprise capability. Phase 1, Year One, was data foundation and governance: a data governance board established and an inventory of all agency data sources completed by month 3; the data governance policy approved and the first 3 data engineers hired by month 6; a data lake prototype operational with the first data sources moved to cloud by month 9; and governance processes proven with the first pilot projects scoped by month 12. Cost: $2.5 million. Output: an organization with clean, governed data and basic technical infrastructure.

Phase 2, Year Two, ran pilots and organizational learning: the first pilot, benefits processing, operational by month 6; a second pilot, fraud detection, operational by month 12 with both systems delivering demonstrated value; and 25 percent of agency staff trained on AI basics by month 12. Cost: $2 million plus $1.5 million of Year One ongoing costs. Phase 3, Year Three onward, targeted a portfolio of 8 to 10 projects, with 4 new projects in development by month 6 and 3 new projects deployed by month 12, at $3 million plus $3 to $4 million annually in ongoing operations. Read those milestones carefully: three new deployments on top of two pilot systems put five systems in operation at the end of Year Three, so treat 8 to 10 as the destination the phase is aimed at rather than a count you can promise for month 12.

The second case is smaller and in some ways more instructive. A small city government wanted AI for service improvements with limited resources, and sequenced one project per year. Year One was pothole detection and road maintenance optimization, chosen for clear return and straightforward data, at $500K. Year Two was permit process automation, chosen because it built on the data capability from Year One, at $400K. Year Three was predictive resource allocation, the most ambitious of the three and dependent on both predecessors, at $600K. By Year Three the city had a proven data team, governance processes that actually worked, organizational confidence, and three systems in production. A city that had attempted all three in Year One would have failed at all three.

What Actually Kills Government AI Roadmaps

Leadership turnover without institutional anchoring. A strategy that lives in a single champion's portfolio dies when that champion leaves. The antidote is faster institutionalization: budget lines, interagency agreements, and legislative mandates that create constituencies beyond the originating office.

Budget rescissions and continuing resolutions. Federal agencies operated under continuing resolutions for an average of 4.3 months per fiscal year between 2010 and 2025. Keep a CR-safe activity list, because data assessments, governance development, and staff training can proceed under prior-year authority while new contracts cannot. Knowing which workstream falls in which category before the fiscal year starts is the difference between a quarter of progress and a quarter of waiting.

Procurement delays. The average federal IT procurement runs 14 months from solicitation to award, which sits inside the 12 to 18 month range measured from requirements finalization, a longer window that includes the work before the solicitation goes out. These are not failures. They are the system operating as designed. If you need a vendor in month 12, issue the solicitation in month 1.

Scope creep driven by political enthusiasm. Yolanda's governance board required a data readiness assessment, a procurement pathway, and a staffing plan for every proposed expansion before approval. This slowed some things down, and it prevented two expansions that would have failed publicly.

Anti-Patterns

• Front-loading ambition. The strategy promises eight projects over three years, so you launch all eight in Year One with the people and infrastructure you already have. Resources spread thin, seven fail, one partially succeeds, momentum dies, and the organization concludes that AI does not work. Phase ruthlessly instead: one or two pilots in Year One, three or four in Year Two, scaling in Year Three. It looks slower and is actually faster, because nobody is context-switching and each step builds on proven capability.
• Ignoring dependencies and promising to handle them in parallel. The data is scattered across legacy systems and governance does not exist, but the pilot starts anyway. Dependencies do not go away when you decline to schedule them; the pilot gets stuck against data, governance, and infrastructure problems, and months pass with minimal movement. Identify blocking dependencies explicitly and resolve them before proceeding.
• No decision gates. You commit to three years and execute blindly, moving from Phase 1 to Phase 2 automatically even though Phase 1 did not go as expected. Pause at each boundary, ask what you learned and whether the plan still holds, and let the answer change the roadmap.
• Declaring a phase you have not reached. A phase is a claim about your own readiness, not a rating anyone confers, so "we are in Phase 2" travels through an organization as fact whether or not the Phase 1 outputs exist. Name the completed deliverable when you name the phase, and be precise in external briefings about what is built and what is planned.
• No contingency. You budget the estimate and schedule the estimate, with no buffer in either. Reality diverges, you are immediately late and over, and you stay that way for the rest of the program while your credibility erodes. Buffer time and money deliberately so that meeting your own estimate reads as delivering early.
• Announcing a date before the contract is signed. Procurement timelines are long, published, and largely outside your control. A deployment date announced during the requirements phase converts an ordinary 14-month award cycle into a public failure, and it does so at the exact moment you most need the vendor relationship to be unhurried.
• Treating a pre-registered threshold as tamper-proof. Registering the success criterion in advance is what makes a retroactive reframing visible; it does not make it impossible. If the person who can waive the threshold is the person whose delivery date depends on passing it, the registration is a formality. Put the waiver somewhere else and record every change to the criterion.
• Funding the build and not the operation. A roadmap that budgets implementation and leaves maintenance, retraining, and monitoring unfunded produces a system that degrades quietly. Nothing announces the failure, the metrics drift, and the eventual discovery lands on whoever is in the chair years later. Budget the operations line before the system is built.

Practice Prompts

1. Dependency mapping. For your proposed AI program, map every dependency across data, governance, infrastructure, people, and compliance. Which is your longest lead item? What has to happen first, and who outside your office controls it?
2. Phase design. Using your organization's AI strategy, design a three-phase roadmap. What is in each phase, what are the milestones, and what is the timeline? Then check each phase boundary against your budget calendar rather than against the project's internal logic.
3. Resource estimation. For each phase, estimate the required resources: roles and FTEs, budget, and infrastructure. Are these realistic given your organization's hiring reality and its appropriations, or do they assume authority you do not have?
4. Gate design. Define the decision gates at the end of Phase 1 and Phase 2. What questions will you ask, what criteria determine whether you proceed, and who has the authority to decide that the answer is no?
5. Risk and contingency. What could derail your roadmap? What time and resource buffers are you building, and what contingency funding do you need? Separately, write your CR-safe activity list: which workstreams can continue under prior-year authority and which stop.
6. Write the transition brief. For your most important current milestone, write the one-page brief an incoming executive would need: what was decided, what was built, what it costs to maintain, and what happens if it is stopped. If you cannot write it, the milestone is not ready to close.

Reflection

Take your organization's AI strategy and develop the three-year roadmap: phases, milestones, resource allocation, contingencies. Then present it to leadership and pay attention to what they ask, because the questions tell you which assumptions are load-bearing for them and which are only load-bearing for you. What would make you more confident in this roadmap: better estimates, a shorter first phase, or a dependency resolved by someone else? Which milestone would survive if you left tomorrow, and which exists only in your head? And if a continuing resolution started next month, what would still move?

Glossary

• Roadmap. A detailed plan for executing a strategy over time, including phases, milestones, resource allocation, and timelines. Substantially more detailed than the strategy it executes.
• Dependency. A prerequisite that must be completed before another task can proceed. Identifying dependencies is what makes sequencing realistic rather than aspirational.
• Phase gate. A decision checkpoint at the end of a phase where stakeholders review progress and decide whether to proceed, adjust, or stay where they are.
• Milestone. A significant point in time by which specific work will be completed, used as a checkpoint for accountability and progress tracking.
• Contingency. Buffer budget set aside for unexpected costs, commonly 10 to 15 percent of the total.
• Time buffer. Additional time built into an estimate to account for realistic delay; a 12-month estimate is commonly planned as 15 to 18 months.
• Contract vehicle. An existing contractual arrangement, such as a Blanket Purchase Agreement, that an agency can order against without running a full new procurement.
• CR-safe activity. Work that can continue under prior-year authority during a continuing resolution, such as data assessment, governance development, and training, as distinct from work requiring new contract authority.
• Transition brief. A short document written before a milestone closes, recording what was decided, what was built, what maintenance costs, and the consequence of stopping, so the work survives a change of leadership.

Related Lessons

A roadmap is the third step in a sequence. Developing an Organizational AI Strategy supplies the ambition it executes, AI Maturity Assessment supplies the honest baseline that determines which phase you are actually starting from, Prioritization Frameworks for Government AI decides which use cases earn a slot, and Building the AI Business Case turns a phase into a funding request. Downstream, AI Pilot Program Design covers the Year One pilot in detail, Moving from Pilot to Production covers the Phase 2 to Phase 3 transition, Establishing an AI Governance Board covers the governance scaffolding Year One depends on, and Federal Acquisition of AI: FAR/DFARS covers the procurement timelines that set your critical path.

Closing

Roadmaps are where strategy meets execution. They take an ambitious vision and make it real through sequencing, resource allocation, and timelines that account for the way government actually works. The organizations that succeed with AI are not the ones with the most ambitious strategies. They are the ones with realistic roadmaps that execute: they phase the work, they respect dependencies, they build in buffers, and they learn at decision gates and adjust rather than defending a plan that was reasonable eighteen months ago.

A roadmap phased realistically will always look less impressive than one that promises everything at once. That is the cost, and it is worth paying, because the ambitious version is the one that collapses in Month Eighteen with a slide still saying Year One. Yolanda's recovery did not come from a better strategy document. It came from rebuilding the plan so that each year was independently valuable and independently survivable, anchoring the milestones in appropriations language and interagency agreements rather than in a champion's enthusiasm, and writing the brief that let the next person continue without her.

Key Takeaways

• Sequence like a bridge builder. Data infrastructure before model development, governance before deployment, contracts before announced commitments. Violating these sequences creates debt that surfaces at the worst possible moment.
• Dependencies are your longest lead items. Data work runs 12 to 18 months, governance 6 to 12, infrastructure 9 to 18, organizational capacity 6 to 24, compliance 6 to 12. Map them before you sequence anything, and do not promise to resolve a blocking dependency in parallel.
• Phase for budget cycles, not project logic. Each phase must produce defensible evidence before the next appropriations deadline. A pilot whose evaluation closes after the budget request is submitted has missed its window by two years.
• The three-year roadmap must work as three one-year roadmaps. Continuity of leadership, funding, and vendor relationships cannot be assumed, so each year has to be independently valuable and independently survivable.
• Design for leadership turnover from day one. Anchor milestones in budget language, interagency agreements, and legislative directives, and write the transition brief before the transition rather than during it.
• Choose contract vehicles in Year One, not Year Two. Scoping a pilot to a vendor already on an existing vehicle compressed ETA's timeline by an estimated 11 months. Identify the vehicles early, because procurement is usually the critical path.
• Resource the foundation and fund the operations line. Phase 1 is genuinely expensive; shortchanging it is how agencies spend the same money accidentally on failures. Then budget 18 to 22 percent of implementation cost annually for operations, maintenance, and retraining, or a future budget office will cut it and the system will degrade quietly.
• Buffer time and money, and gate every phase. Plan 15 to 18 months for a 12-month estimate, staff above your headcount estimate, hold 10 to 15 percent contingency, and pause at each phase boundary to ask whether the plan still holds.
• Keep a continuing resolution-safe activity list. Data assessment, governance development, and staff training can proceed under prior-year authority. New contracts cannot. Know which workstream is which before the fiscal year begins.
• Scope creep is a governance problem, not a technology problem. Require a data readiness check, a procurement pathway, and a staffing plan before approving any expansion. Enthusiasm is not a deployment plan.

Frequently Asked Questions

Our leadership wants results in the first year. How do I sell a foundation phase? Do not sell it as a foundation phase. Sell it as the year that produces the evidence the next budget request depends on, and put a single bounded pilot inside it with a success threshold registered in advance. That is what ETA did: the data assessment and the governance board were the substance, and the three-state fraud detection pilot was the result leadership could point to. The pilot also has to be scoped so its evaluation closes before the budget request deadline, which is the constraint that should set its start date.

What happens to the roadmap during a continuing resolution? A good deal of it can continue, which is why the CR-safe list is worth writing before you need it. Data assessments, governance development, and staff training generally proceed under prior-year authority. New contracts do not. The practical consequence is that anything requiring an award should be sequenced to avoid the risky window if you can, and anything that can absorb a freeze should be scheduled where a freeze would otherwise leave the team idle.

How do I stop the roadmap dying when my sponsor leaves? Move the commitments out of the sponsor's portfolio and into structures that outlive them: appropriations and report language, interagency agreements, and recurring base-budget lines rather than special initiatives. Then write a one-page transition brief for every major milestone before that milestone closes, covering what was decided, what was built, what maintenance costs, and what stopping would mean. A directive to report to an appropriations committee by a fixed date survived three acting secretaries at ETA. Enthusiasm survives nobody.

We are a small city, not a federal agency. Does any of this apply? The sequencing does, and the small-city example shows the shape: one project per year, each chosen because it builds on the capability the last one created. Pothole detection first for clear value and straightforward data, permit automation second because it used the same data capability, predictive allocation third because it needed both. By Year Three there was a working team, governance that had been exercised, and three systems in production. Attempting all three at once fails all three regardless of the size of the organization.

How much buffer is defensible without looking like padding? Time buffers of the kind that turn a 12-month estimate into a 15 to 18 month plan, staffing a little above your headcount estimate, and a contingency reserve of 10 to 15 percent are all standard and explainable. The argument that wins is the credibility argument: an estimate with no buffer is missed immediately and every subsequent number you present is discounted, whereas an estimate you meet or beat makes the next request easier to fund. State the buffer explicitly rather than hiding it inside line items, because a hidden buffer looks like padding when it is found.

When is it right to stop rather than adjust? At a decision gate, and on criteria you wrote earlier. The gate question is not whether the team worked hard; it is whether the phase produced the output the next phase depends on. If Phase 1 did not deliver governed data, Phase 2 pilots will stall regardless of enthusiasm, and moving anyway converts a recoverable delay into a public failure. Stopping at a gate with a documented reason is a defensible decision. Discovering the same fact in Year Three is an audit finding.