A Brief History of IT Share-in-Savings Contracting in the Federal Government
This is the second post in a four-part series. In our last post, we laid out the case for why the federal government should consider revisiting the practice of share-in-savings (SiS) contracting in order to deal with their legacy-systems crisis. Now we look back at some of the government’s experience with applying SiS to information technology (IT) contracts, as we build up to the unveiling of our Agile Share-in-Savings Model.
Believe it or not, share-in-savings contracting is a technique permitted under existing federal regulations. Agencies can launch projects with little or no upfront funding. Instead, they pay a contractor a share of the savings (or revenue) generated from the contracted effort. The better and quicker the vendor performs, the better they do financially. The worse and slower they perform, the worse they do financially.
Given these characteristics, the SiS model is by far the most results-oriented, performance-incentivized, and risk-mitigated way you can structure a contract. (The only thing that beats it is Star Trek’s utopic economy where people produce things out of pure good will in the name of societal betterment.) In its most extreme version, total payment is based wholly on a percentage of the savings. In other cases, total payment is based on a fixed fee plus a lower percentage of the savings.
You might ask: why not do all contracts this way? As with any tool, it’s not appropriate in all situations. SiS works best when there is an objective measure of savings that can be readily constructed and calculated, and where the savings is large compared to the estimated costs to achieve the savings. This allows firms to be clearly incentivized with a fraction of the savings, and where the government clearly realizes long-term benefit from the completion of the work. Under such circumstances, it’s appropriate — and effective. That’s why the private sector has been making use of it for decades, and the government as well, primarily through energy savings performance and value engineering contracts.
Around the turn of the 21st century, the government attempted to jumpstart the adoption of SiS IT contracts:
- 1996: Clinger-Cohen Act passes. The passage of this act by Congress included a pilot program that authorized the use of SiS contracts for IT (see Section 5311). However, only the Department of Education participated. Other agencies didn’t for a variety of reasons, including: cultural resistance, absence of formal policy, cumbersome governance, and perceived complexity.
- 1999: Department of Education Student Financial Aid program uses SiS contracting. In a now famous case study, the Department of Education engaged with Accenture to consolidate several legacy systems under the Student Financial Aid program with “zero” upfront dollars. Accenture recouped their costs and then some by generating nearly $40M in savings. Openness, collaboration, and “equal partnership” between the two were critical success factors.
- 2002: E-Government Act passes. Discouraged by the lack of adoption under the Clinger-Cohen Act pilot program, Congress once again tried to pave the way through the passage of key provisions in the E-Government Act (see Sections 210 and 317). The act provided a pilot period until September 2005 in which agencies could enter into contracts exempt from the “upfront funding of termination liabilities” provision scribed in appropriations law. A termination liability is an agreed-to amount that the government pays to a contractor if a multi-year contract is prematurely cancelled by the government. With SiS, termination liability comes into play when (1) the contractor won’t otherwise agree to the multi-year contract (that is, prefers to hedge their bets) and (2) the government can only pay the contractor out of savings realized in future years. If savings accrue in the same year, then termination liability doesn’t apply. Another important aspect of the pilot gave agencies the authority to retain a portion of any savings for reinvestment in other programs. Last, but not least, the act tasked the General Services Administration (GSA) to serve as the central authority for SiS IT contracting.
- 2003: GSA establishes share-in-savings program office. Per the E-Government Act, the GSA established a central office to drive government-wide adoption through activities such as promulgating official policy, helping agencies identify suitable projects, and developing tools.
- 2003: Government Accountability Office (GAO) releases report called Commercial Use of Share-in-Savings Contracting. In response to a request by Congress, GAO produced a research report that examined critical success factors found in industry’s use of SiS (for example, top management commitment), along with recommendations for how agencies should take the findings into account.
- 2004: GSA awards government-wide share-in-savings contract. As an additional catalyst, GSA awarded a $3B blanket purchase agreement to six vendors to create a federal-wide market for share-in-savings IT projects.
- 2005: Key provisions in the E-Government Act expire. Despite attempts to keep legislative drivers in place, including a renewal of key provisions in the E-Government Act, as well as a proposed bill to make $240M worth of federal purchases eligible for SiS, those measures were met with lack of interest by Congress and the Bush Administration, and even opposed by so-called “watchdog” groups, namely Project on Government Oversight. Not one SiS contract was awarded under the aegis of the E-Government Act.
- 2005: GAO releases report called Share-in-Savings Initiative Not Yet Tested. In this report, GAO surveyed the federal government’s progress with implementing the E-Government Act’s SiS authority and found a number of inhibitors, including lack of guidance, lack of training, and concern among officials that funding for termination liability still needed to be obtained. The conclusion: SiS IT contracting remained untested.
Despite the flurry of activities, SiS fell by the wayside — never to be revisited again. So what were the challenges that caused it to languish? And what can be done to address them a second time around while using it as a means to modernize the federal government’s legacy systems?
Stay tuned for those answers in the next post.