Steve Kelman suggests that share-in-savings contracting could help agencies solve the funding conundrum and tackle legacy IT.
At the beginning of the millennium, I was the leading advocate, along with then-Rep. Tom Davis (R-Va.), of an innovative form of contracting called “share-in-savings.” The basic idea was that contractors would be paid, all or in part, though the savings their efforts generated.
To me, the main appeal was that it gave the contractor a strong profit incentive to perform what could be risky work. No savings, no payment to the contractor. Lots of savings, lots of payment; because of the risk, the government would need to accept that a successful contractor would make lots of money.
This struck us as the ultimate form of performance-based contracting. (People hadn’t yet thought about challenges, which rival share-in-savings for the ultimate performance-based crown.) At the same time, its more immediate appeal to government IT folks involved tight funding environments -- share-in-savings contracting could be a way to get more IT without appropriated funds.
At the time, Davis got Congress to pass a three-year experiment that specifically authorized share-in-savings -- which shouldn’t have been necessary because it was just a form of multiyear contracting that was already allowed in the Federal Acquisition Regulation. More importantly, the legislation allowed a three-year reprieve from some special advance-funding requirements that made share-in-savings contracting more difficult for the government.
Despite the encouragement, share-in-savings did not get very far outside the area of contracts for energy savings in federal facilities, paid for by giving the contractor a share of the energy savings their efforts generated. To use it in IT, it was necessary to come up with a project with a very high ROI, enough to pay the contractor through the savings. There was opposition from the anti-contractor Project on Government Oversight, which worried about high profits even if these grew out of large savings to the government. And it was a complex form of contracting, where the government didn’t have very much expertise.
So the pilot was not renewed, and interest in share-in-savings waned -- although I discussed it as one of my recommendations for procurement policy in the new administration published by the National Academy of Public Administration late last year, part of a push for more contracting that “pays for success.” The Department of Energy tried to apply this model to a data center optimization project in 2013, but it struggled to secure the necessary approvals.
Now the share-in-savings contracting cudgel has been taken up by a new champion in a new context. Chris Cairns, a co-founder of 18F (he had earlier been in private equity and a web startup), has written together with fellow 18F alumnus Robert Read a series of four blog posts -- the last, with the recommendation to be discussed below, is linked here. He calls it “agile share-in-savings contracting.”
Cairns and Read’s idea is to use share-in-savings contracting to help with the modernization of legacy systems. Operations and maintenance (much of it for legacy systems) are gobbling up 75 percent of federal IT spending. For 5,200 of 7,000 legacy systems, they write, all spending is going to O&M, leaving zero dollars for modernization and improvement.
The return on investment from rewriting legacy code can be very large, since the number of lines of code needed in a rewritten version is much smaller, and often expensive proprietary licenses can be replaced by free open source. Read estimates that for systems more than 10 years old, savings off baseline operations and maintenance can be 80 percent. This makes legacy system modernization a viable share-in-savings project, even when no funding is available, as has frequently been the case with trying to deal with legacy systems.
Cairns and Read’s twist is to modernize using agile software development, with modernization occurring in small chunks of the existing code. This has a number of advantages. It starts generating operations and maintenance savings much quicker, rather than waiting until the whole project is completed. It lowers vendor risk, an especial issue in a share-in-savings environment that puts the vendor into an inherently riskier situation. The simpler nature of these chunks also makes developing the contract much easier than it would be for a massive all-at-once effort to deal with an entire legacy application. And chunks make small business participation in share-in-savings more feasible, because the worry about large cash flow requirements are less.
Interestingly, like many IT professionals in government the last time this issue was on the table, Cairns and Read see share-in-savings as a lifeline in an environment where appropriated funds are not available for modernization. They suggest that taking the conventional appropriated funds route would be better (because it's less complicated) if funds were available, but the prospects for a fully funding IT modernization effort seem slim. In an email exchange, Cairns also agreed that legacy modernization was definitely not risk-free, so there would be advantages to using share-in-savings in terms of the incentives for contractors.
The Cairns and Read blog is long and quite complex, and I am only able to scratch the surface of their ideas here. I would urge interested readers to read their entire post. I hope many do so, because the legacy system problem in federal IT is a huge one, and agile share-in-savings could be a way out.