A Short History of the Government-Wide Schedule's-Based BPA

(This article was published on LinkedIn October 15, 2025.)

Sometimes the unexpected obviousness of something is hard to see.  I did a little research answering the question “What role does the Government-wide Schedule’s-based BPA play in the federal marketplace?”  In a previous piece I show that the explosion of Government-wide Schedule’s-based BPAs exploded after GSA was unsuccessful at closing NASA’s SEWP program in 2007.  It was shortly thereafter that I began working at the General Services Administration where Schedule’s-based BPAs were the answer… now what was your question?

What I had forgotten to capture in the previous analysis was the predecessor for the Schedule’s-based BPAs in the form of GSA’s SmartBUY Program.  Prior to 2005 BPAs on Schedules were not really a thing, but GSA needed to come up with a way to address the calls for coordinating some government-wide software agreements.  With the E-Government Act of 2022 OMB began urging agencies to consolidate purchases of common IT products to “leverage the collective bargaining power of the federal government” to obtain better pricing and terms for commercial software and related purchases.

The GSA SmartBUY program was designed to:

• Negotiate government-wide enterprise agreements for commonly used software.

• Eliminate duplicative contracts across agencies.

• Reduce costs by aggregating demand and improving licensing efficiency.

• Ensure compliance with software license terms and reduce audit risk.

• Standardize enterprise terms and conditions.

The companies that the GSA SmartBUY office established agreements with Microsoft, Oracle, Symantec, McAfee, Adobe, Trend Micro, and IMB (for Lotusnotes).  The SmartBUY initiative did not achieve the results of what they sought. (* BGov only lists the Oracle Smartbuy BPA that was under DISA and a GeoSpacial SmartBuy BPA that had little to no spend go through it).

Although SmartBUY was short lived it gave GSA’s Schedules program a position through which to engage in the Federal Strategic Sourcing Initiative.  It was through this initiative where GSA’s use of the Government-wide Schedule’s-based BPA really took off.  BPAs for laptop and desktops, office supplies, janitorial supplies and services, and later telecommunication expense management services, were initially part of this initiative, and under the same assumptions and premises that underpinned SmartBUY.

GSA’s Information Technology Service then utilized the Schedule’s-based BPA to establish agreements driven by the Obama Administration’s initiatives.  When CIO Vivek Kundra introduced Cloud Computing to the federal government, GSA established the Infrastructure-as-a-Service and Email-as-a-Service Schedule-based BPAs.  As CIO Steve Van Roekle introduced his Digital Government Strategy, GSA responded with Schedule-based BPAs for Wireless Telecommunications under the FSSI Program. 

As SmartBUY transitioned to FSSI, FSSI transitioned to Category Management.  Through Category Management the Government-wide Schedule’s-based BPA continues to be GSA’s answer regardless of the question. Today GSA lists BPAs for Express Business and Analytical Services, Express Logistics Services, Express Technical Services (R&D), Express Technical Services (Non R&D), Maintenance and Facility Repair, SCRM Illumination Software, 2GIT, Government Laptop and Desktop, and the Ascend BPAs for IAAS and PaaS Cloud Computing.

This now gets us to OneGov – the current brand that seeks to execute the same principles carrying the same assumptions as the GSA SmartBUY program and through the same Schedule’s-based mechanism.

This short overview does beg a few questions:

After 20 years of attempts, when will the Schedule’s-based interests for a Schedule’s-based world realize that contracts are not what consolidates?

Who is responsible for the creation of mechanisms that drive up the costs for industry and the contracting base, costs that end up ultimately being transferred to federal buyers? 

Is it OMB and NASA’s fault that GSA has engaged in what appears to be perpetual vehicle creation for the past 20 years?

**********

What purpose does the Government-wide Schedules-based, government-wide BPA serve?  This is a question that is now being discussed.

In some cases, Government-wide Schedule’s-based BPAs were (and still are) attempts at the enterprise government approach to purchasing, though for reasons I covered in a Washington Technology article this does not appear to be workable in a federated environment.  Though these acquisition vehicles have not succeeded in achieving the consolidation outcomes sought, they are the tool that GSA uses to construct such agreements.

The other cases, GSA’s use of the Government-wide, Schedule’s-based BPAs are the tool of the trade to introduce new technology into the federal environment.  That was the case with the cloud computing agreements in the early Obama Administration, and more recent Supply-Chain Illumination Solutions found on SCRIPTS today.

In the first case GSA inadvertently increases costs for buyers as industry passes these costs along and spreads it out, and the track record of achieving the outcomes sought appears ineffective.

In the second case, GSA also increases costs for buyers as they use a contract tool to advance technology adoption that often lacks maturity or could be addressed in another way.  This mechanism appears inefficient when it comes to introducing new technology.

These were the conditions we knew in 2012 as government was transitioning to a new, more diverse set of platforms for mobile technology.  Blackberry was managed by their enterprise server at the time, and those controls were sought as android and iOS devices were introduced into government as a tool. 

You can guess what GSA recommended for a path – create a BPA for that.  That was the assumed approach that everyone else took and the answer that everyone wanted to hear.  Our response was “No.  I think we can find a better way to advance adoption without increasing costs.”  So, a small band of rebels in that agency, along with some collaborators at DHS, DOJ, and DOD constructed a different approach that a) generated common requirements that solutions would have to meet and agencies could use to procure, b) identified and vetted solutions that met those requirements, and c) then identified the contractual mechanisms through which agencies could procure.

In short we defined the specific IT category (as with category management practices), developed requirements (that all agencies could leverage, making for a predictable market), identified solutions (referred to as ‘potential sources of supply), and then instead of creating another BPA to be services we just identified the vehicles through which they could be procured (saving the expense that industry bores in responding to positions on a BPA and then serving those agreements afterwards).

That was not the end of the story, however.  This community then extended the definitions beyond MDM to apply to the entirety of the definable mobile ecosystem.  Whether it was mobile application security tools, secure application development practices, middleware capabilities for integrating data flow and structure to an enterprise infrastructure… we defined these areas, wrote language found in requirements documents, identified tools and solutions that were in use or had the potential for federal use.  We did this without the need of establishing BPAs, thereby raising costs, but rather with information share (requirements, solutions, deployments, costs) within knowledgeable government communities, and then through information share, exchanges, and problem solving between government and industry.

ATARC-MSCT-Report-Navigating-Future-of-Mobile-Services.pdf

This was the right call for introducing new technology into the federal marketplace, and consistent with workable category management practices.  It gave the space time to evolve (had a BPA been created the solutions have already been purchased within the first year of establishing them – MAAS360 to IBM, AirWatch to VM Ware just to name two examples). It was much more efficient and effective than would have been the case through a Government-wide Schedule’s-based BPA.

As for whether these Government-wide Schedule’s-based BPAs are the right for an Enterprise-Government approach to driving down pricing, the claim that they have done so would be unfounded.  In fact, information sharing between government CIO offices about their requirements, their solutions, their deployments, their costs, and their agreements produce better results than a government-wide vehicle alone can achieve.

Information can translate to shared knowledge which can drive savings if that information is appropriately shared within government and analyzed within the context of agency conditions.  NASA’s program has been a source of information for mission driven agencies across government.  They share this information that forms the basis of these conversations between agencies because:  a) the data is accurate, b) the data is detailed, c) the data shows context, and d) the data is complete. 

These are conditions not currently found within GSA’s Schedule’s program, which ends up being an unspoken additional third reason why Government-wide Schedule’s-based BPAs were used.  It was the only way for GSA to get data to their program.  TDR is the means for GSA to address that problem.  It will be now up to industry to see how efficiently GSA can do that.  Does requiring detailed reports from industry monthly (the essence of the TDR policy) seem like an efficient and effective way to do so while keeping costs and resources down (for industry as well as for GSA) vs. the single-platform approach that NASA has proven to deploy with consistency?

Features of the Architects of Inefficiency and their Coalition of Schedule-Based Interests.  As Johnny Stugatz tells me, there is money to be made in inefficiency.  It is too bad it comes at a cost.