Every few years, the federal government rediscovers its appetite for efficiency, and the results are usually a stack of slideware. GSA's Federal EOA Playbook, published on June 3, 2026, is a welcome exception. It arrives on the back of a genuine mandate, based on a series of executive orders (14158, 14179, 14210, 14219, and 14222) and OMB memoranda directing agencies to streamline operations, cut costs, and shift work from low-value to high-value. Its premise is disarmingly simple: before you spend a dollar automating anything, ask whether the work should exist at all (Eliminate), whether it can be done better (Optimize), and only then whether a machine should do it (Automate).
A field guide that earns its keep
Read it as a practitioner, and the playbook holds up. This is a method, not marketing. It runs an EOA effort through a real lifecycle (Opportunity Assessment, four weeks; Solution Planning & Design, eight weeks; and an ongoing Implementing & Sustaining phase), and it borrows honestly from lean, root-cause analysis, and agile rather than inventing a proprietary vocabulary. It measures with discipline: capacity identified, capacity created, realization rate, and a dollar value on returned hours. And it is anchored by a case study with the kind of numbers most transformation decks never dare to print.
GSA's Office of the Chief Financial Officer reduced its organization from 450 to 343 full-time employees (a 24% reduction achieved through attrition and a hiring freeze rather than layoffs), while employee viewpoint scores rose from 66 to 88. Within the same window, timely funds certification climbed from 87.7% to 95.9%, aged invoices fell from 2.58% to under 1%, the $40M chargeback backlog was cleared, and every audit material weakness was cleared. Enterprise-wide, GSA reports more than 190 automations and over two million hours of workload returned since 2019, with a Million Hour Challenge now aiming to shift another million hours from low- to high-value work across FY26–27. These are not vanity metrics.
The layer the playbook implies but never names
Here is a question worth sitting with. The playbook is, at its core, applied enterprise architecture; it never uses the words. Value stream maps, current- and future-state process models, an automation decision tree that sorts work by data structure and business rules, a prioritization matrix weighing feasibility, strategic alignment, and impact: that is, business, data, application, and technology architecture, discovered one opportunity at a time.
And "one opportunity at a time" is precisely the limitation. That connective tissue (the shared, authoritative model of an agency's capabilities, processes, systems, and data) is enterprise architecture. Layered onto EOA, it changes the exercise in four concrete ways.
1. You can't survey your way to the biggest opportunities
The playbook offers three ways to find EOA candidates: value stream mapping, staff surveys, and reviews of known and emerging challenges. All three are sound and essentially bottom-up: they surface what people already feel. An enterprise-architecture practice adds the top-down complement. A business capability map and an application portfolio view systematically expose redundancy (for example, three systems quietly performing the same travel-approval function) rather than relying on someone to flag it in an open-text field. Notably, the playbook's sample project list already includes "eliminate a duplicative data-entry application" and "centralize dashboarding and reporting." Those are portfolio-level insights that an architecture view surfaces on day one.
2. Elimination-first needs an authoritative source of truth
The playbook is right to prioritize Elimination over Optimization and Automation: the cheapest work is the work you stop doing. But you cannot confidently retire a requirement, a report, or a control if you cannot see who depends on it downstream. Elimination is the highest-yielding of the three moves and also the riskiest; its safety rests entirely on the underlying business architecture. EA's traceability (from strategic driver to capability to process to system to data) is what lets an executive say, "this control is genuinely redundant," rather than "no one in the room objected." Without that map, elimination is a gamble; with it, it becomes the program's best bet.
3. The automation estate is a portfolio, not a pile
One hundred and ninety automations are both an achievement and a warning. Every bot is a small, brittle integration that breaks when the system beneath it changes, and a fleet of them, left ungoverned, becomes exactly the shadow IT and technical debt that enterprise architecture exists to prevent. The playbook's own automation decision tree (RPA, APIs, and OCR for structured work; natural language processing and document understanding for unstructured work; AI and machine learning where situational human judgment is required) is a reference-architecture conversation waiting to happen. Governed as a portfolio, with shared services and reusable APIs, those one-off bots become durable capabilities. The executive question shifts from "can we automate this?" to "does this belong in our target architecture, and can we reuse what we build?"
4. No automation gets ahead of its data
The very first fork in the playbook's automation decision tree asks whether the process data is structured or unstructured. That is a data-architecture question, and it is decisive: AI and automation ambitions live or die on data quality, lineage, and access. An agency that invests in canonical data models, governed sources, and APIs in place of screen-scraping converts the "major projects" and "thankless tasks" on the playbook's feasibility-and-impact matrix into quick wins. Skip that investment, and the same projects stay expensive forever.
Sustaining across administrations is a governance problem
The playbook is admirably candid about its biggest risk: sustaining improvements "beyond changes in administration." Its answer is to shift coalitions and communities of practice, which are necessary but personality-dependent and easily lost when a sponsor moves on. Enterprise architecture offers a durable complement: institutional governance. Capability-based planning, an architecture review board, and alignment with an architecture framework give EOA a home that outlasts any one leader. Wire the EOA program dashboard into the architecture repository and the configuration management database so "capacity created" stops being a number in a spreadsheet and becomes a traceable line from a mission outcome to the system that delivers it.
A word on the scoreboard
Credit the playbook for measuring at all; most efficiency drives don't. But a senior executive should read the hours-saved figures with healthy skepticism, and the playbook invites exactly that: it notes its capacity estimates are unaudited and values returned time at a flat $70 an hour. Hours are an input; mission outcomes are the point. The right instrument is already in the appendix: the performance logic model, which forces the line from inputs and processes through to outputs and outcomes. Judge the program by whether funds are certified faster and audits come back clean, not by bot-hours logged.
The verbs and the blueprint
GSA has produced the most useful practical field guide to federal process improvement in years, and its results deserve the attention they will get. The opportunity for the next agency that picks it up is to supply the layer that the playbook leaves implicit. Eliminate, optimize, and automate are the verbs. Enterprise architecture is the blueprint that tells you where to point them and why the gains still stand when the next administration arrives. You can read more about GSA EOA by clicking here