A Model for Agile Share-in-Savings

— by Chris Cairns and Robert L. Read, PhD

This is the final post in a four-part series. In the first post, we laid out the case for why the federal government should consider revisiting the practice of share-in-savings (SiS) contracting as a necessary means to deal with their legacy information technology (IT) systems crisis. In the second post, we gave a brief history lesson on the federal government’s experience with SiS to IT. In the third post, we listed out some of the government’s challenges with applying SiS to IT and our ideas for handling them. And we now present a model for a modern Agile Share-in-Savings approach applied to software and information technology. Later on in this post, we will discuss how to generalize this model a bit.

For concreteness, please imagine that you’re a Chief Information Officer (CIO) and in your portfolio includes a legacy software system that requires a $10M per year operations and maintenance (O&M) budget. Let’s pretend it’s a case management system, named CMS, since many agencies have a case management system of one kind or another. A case management system is fundamentally just a database with a some important, slowly evolving business rules and a user interface. Every year, you have to pay a contractor to adjust the business rules to match minor changes in regulation mandated to you by Congress. You would like to improve the efficiency of your staff by improving the user interface (UI), but the system is so antiquated that improving the UI is expensive and you hesitate to invest in it.

Let’s consider a spectrum of financial situations. At the lucky end of the spectrum, you’re a CIO to whom Congress has appropriated 100% of the expected cost of modernizing the CMS. You don’t need strictly need to use share-in-savings, because you have enough money for a traditional contract. However, we would encourage you strongly to insist on an agile rewrite of your legacy system as outlined in the model below.

At the other end of the spectrum, you have zero budget beyond the $10M per year currently appropriated. At first glance, it seems that your hands are completely tied. The Agile Share-in-Savings Model offers a way, perhaps the only way, to get the CMS rewritten with no additional budget. Of course, any given CIO may find themselves to be somewhere between these two extremes, so understanding the Agile Share-in-Savings Model may be useful to them.

Assumptions and Principles

Let’s now state some assumptions and principles of modern software development before we present the model in narrative and diagrammatic form. We don’t expect every reader to immediately agree with each of these.

1. The best and lowest-risk way to rewrite a legacy system is with the Strangler Pattern, as articulated by Martin Fowler. The pattern requires the establishment of clear modules based on specific Application Programming Interfaces (APIs.) As the APIs are defined, individual modules can be rewritten, allowing for a gradual and therefore a low-risk rewrite of the legacy system that remains operating at all times, rather than a monolithic, high-risk rewrite requiring a massive launch effort.
2. It’s possible to find technical talent that can look at the legacy codebase and carve out small, independent “chunks” representing 1% of the total codebase. These pieces can have a clearly defined API and can have automated tests written for them providing at least partial test-coverage of that functionality. This talent could be given a new role moniker, such as Legacy Refactoring Engineer. A resource that didn’t exist four years ago, 18F, can potentially provide this role. Assume further that to pay this engineer to define such a chunk is relatively cheap compared to the cost of actually rewriting the chunk.
3. We think that by clearly defining APIs it’s possible to create modules that are transparent and independently codable. This could be named the “Independent Modularization Principle” (IMP), or, more bluntly, the “No Vendor Lock-in” principle. By defining clear enough APIs, it’s possible for each chunk to be coded by independent vendors, although each vendor may need to be part of a vetted pool that has some overall understanding of the operating environment, data types, coding styles, etc. Informally speaking, good APIs encourage good cooperation, or to quote Robert Frost: “Good fences make good neighbors.”
4. Assuming you had a firm in place with some familiarity with the CMS codebase, it would be possible and desirable to specify, code, test, and evaluate and deploy a 1% “chunk” within a single quarter of a year. Customarily this is more a challenge within government than within the software industry as a whole, which has largely moved to very rapid release cycles. Prestigious firms such as Google and Facebook tend to release code on a daily basis and don’t even publicly use “release numbers.”
5. If you got a 1% chunk rewritten in the first half of your year, you would be able to observe a tiny decrease in your operations and maintenance budget for that year. Note that this decrease need not be 1%, because, after all, rewriting that 1% does not make its maintenance go away completely. However, it might result in a 2-fold or 10-fold reduction in the lines of code it uses, so it’s reasonable that you may be able to negotiate or pay out 1/4 or 1/2 of the 1% rewrite. Specifically, in this example, we’re assuming that you can pay out $25,000 (1/4 of 1%) or $50,000 (1/2 of 1%) less than your full $10M budget in this fiscal year if you genuinely believe the decrease in the complexity and improvement in the code quality of your legacy CMS deserves it.
6. A firm that saves the government $1 this year in a way that is expected save $1 every year into the future should get much more than $1 in reward. (In other words, firms should get something related to the Net Present Value (NPV) of expected future savings.)
7. However, firms should not get the entire future savings stream — so for simplicity, we’ll establish the principle that firms should always get one-half of the savings that they provide. This principle ensures that the taxpayer is always benefitting from every payout. We call this principle the “Taxpayer Equity Principle” (TEP).
8. We assert as a principle of pure Agile Share-in-Savings approaches that firms are paid only a fraction of actual realized savings. We call this the “Actual Savings Only Principle”. A scheme that compensates firms (for example, via cost reimbursement or a fixed fee) in addition to this amount is quite useful, but for clarity we would call such a scheme a “Hybrid Agile Share-in-Savings” model.
9. It will be politically acceptable for firms to get large rewards for low-effort but clever solutions, potentially based on free and commercial off-the-shelf software (COTS) solutions. We call this the “Lazy Programmer Principle,” after the laziness virtue of the three virtues of a programmer enumerated by Larry Wall. For example, if a firm provides a one-line solution to a problem by including an open-source tool, such as the full-text search engine Lucene, to replace an entire 5,000-line body of ad-hoc code for searching, it must be politically acceptable for them to be paid on the basis of the cost savings, not the effort expended.

Under these assumptions and principles, we now present a diagram of the Agile Share-in-Savings Model, and will then explain it by following the story of a single chunk of work, and how it relates to the the actors who deal with it, and the money and assets that flow around it. We beg the reader’s patience in studying this diagram. In the famous quote attributed to Albert Einstein: “Everything should be made as simple as possible, but no simpler.”

The Story of Using an Agile Share-in-Savings Approach

Once upon a time, there was a CIO who had a legacy $10M per year software system that was limiting her ability to provide service to the taxpayer. However, she had no budget to modernize it. So she established an Agile Share-in-Savings approach to rewriting it.

First, she established a vendor pool of firms vetted for confidence working in agile methodologies and willing to assume financial risk in order to get a possibility of great reward. She argued that many vendors need to be able to see the code in order to effectively bid on the rewrites. Her problem would have been solved if her system was completely open-source, but alas it was not. She worked with her staff to develop a security policy to allows the vendors in the pool to examine most of the code before being bidding on a chunk to refactor.

Then, she hired a Legacy Refactoring Engineer who was a government employee, and asked them to start defining clearly-defined, testable, chunks of her legacy system to be rewritten. She furthermore demanded that each of these chunks have some automated tests written for them, in order to make it easier for firms to both evaluate how hard rewriting the chunk would be and for them to be sure when they had done a good job.

Next, she got a bunch of financial and procurement professionals, with whatever involvement from Congress and the Office of Management and Budget (OMB) is necessary, to create a new kind of financial asset: Future Agile Share-in-Savings Asset (FASiSA). This entitled the bearer to a fraction of the future savings that the government realized for the next five years on her legacy system.

Then, she hired a highly technical Code Quality Assessor, whose job it would be to evaluate the expected savings of a newly rewritten chunk. The Assessor would choose to accept a rewritten chunk or not, effectively saying “yes, this is an improvement and we should deploy it right away” — or not. Furthermore, the Assessor would assign the chunk a score, effectively saying “this 1% chunk is going to only cost us X% to maintain compared to the cost of the older 1%.”

Finally, she spoke to her staff and made sure that they were ready to deploy a chunk if they got one. This stretched her staff outside their comfort zone, and they had to think about roll-back procedures, how to inform users (or not) of the deployment, what downtime there would be (if any), but eventually she got a solid rapid deployment plan in place.

Then she sets the model in motion. Please try to follow the life-history of Chunk #7 in the diagram as you read through this narrative:

1. Phase 1: The Chunking. The Legacy Refactoring Engineer defined some chunks that they thought were each about 1% of the complexity and O&M budget for the project. They didn’t have to “chunkify” the whole codebase, just the first 10% to get started. They wrote some good automated tests and a clearly-defined API for each chunk, in particular Chunk #7.
2. Since Chunk #7 was defined to be 1% of the legacy problem, the financial and procurement professionals created a new asset, a 1%-for-the-next-five-years Future Agile Share-in-Savings Asset (FASiSA). Whether this asset paid out in the future would depend entirely on if the government was able to decrease its future budget. If something went wrong and the budget did not go down, the asset would pay nothing. Furthermore, by the Taxpayer Equity Principle, 1/2 of the asset would go to taxpayer, and 1/2 to the owner. So in an ideal and unattainable situation, this asset would pay out $50K (1/2 of 1% of $10M) over each of the next 5 years, or $250K. Similarly, a cash reward of up to $50K was attached to Chunk #7 to be paid out in this fiscal year, in the unlikely event that the maintenance costs for Chunk #7 went to $0.
3. Phase 2: The Auction. Chunk #7, with its automated tests, Future Agile Share-in-Savings Asset, and maximum in-year cash reward were submitted to the vendor pool for bidding. These vendors bid on the the potential reward (subject to the Assessor’s decision) on Chunk #7, with the lowest bidder winning both the in-year cash reward (the bid amount) and the Future Agile Share-in-Savings Asset. This chunk is 1% (or $100K) of the $10M O&M budget. By the Taxpayers Equity Principle, the government will accept a maximum bid today of $50K (½ of 1% of $10M), and potentially will pay out $50K for the next 5 years, or $250K. Even though it is very unlikely that full amount will be awarded by the Assessor, the future revenue stream may be enough to make firms submit low bids for the work. As it happens in our example, Alice Inc., is the lowest bidder with a bid of $20K, assigning a $20K maximum cash reward for Chunk #7.
4. Alice Inc. works for three months on Chunk #7 and develops a candidate solution, which they submit to the Code Quality Assessor.
5. Phase 3: The Judgement. New Chunk #7 use many fewer lines of code than Old Chunk #7, but the Assessor refuses to use a straight-line model since they don’t want firms to cut corners by writing cryptically short code. Nonetheless, the Assessor assigns a score of 75% to the New Chunk #7. This means they believe New Chunk #7 will only have an ongoing maintenance cost of 25% of what the old costs were for that Chunk. In this case, that amounts to an in-year saving of $75K, which the Agency will use to pay Alice Inc., the Code Quality Assessor, and the Legacy Refactoring Engineer.
6. The CIO’s office deploys New Chunk #7, and finds that after a week there are no serious bugs reported, so they don’t roll it back and announce it complete.
7. The Agency gives Alice Inc. its judged cash reward of 75% of $20K, or $15K. They also give Alice Inc. a Future Agile Share-in-Savings Asset worth 0.75% of one-half of the yearly savings for the next five years. In the diagram, this is represented as 3/8%. Since the Assessor and the Legacy Refactoring Engineer are probably both government employees, they are in-agency employees or they get paid a simple predetermined fixed fee (in this example, $5K and $10K respectively) via inter-agency agreement, and their fees are hopefully quickly recouped by in-year savings.

Thus ends the life of Old Chunk #7, replaced by New Chunk #7. Concurrent to this, other chunks may be being worked on by the firms in the vendor pool. The software is slowly improved with each Chunk that is processed. If we imagine that the first 10 Chunks have the same life history as Chunk #7, and that all of our assumptions hold true, then at the end of the deployment of 10 Chunks, the software system has 92.5% of the complexity and budget that it started with. (Remember, these 10 Chunks only represent 10% of the legacy system in our hypothetical scenario.) So Instead of a $10M per year budget, in now has a $9.25M per year budget (a reduction of $750K). More importantly, all of the actors have developed experience and trust with the process, which may enable a higher percentage of the legacy CMS to be rewritten in the coming years until the system is deemed modernized.

Follow the Money

Let’s examine the profit-and-loss statements for each of the players for just this year to understand what has happened to the money.

Alice Inc. is relatively happy. They have a revenue of $15K for this year in exchange for their labor, but they have an asset that might be an income stream of $37.5K every year for the next 5 years, or $187.5K in absolute terms. One can certainly argue that no firm would ever do so much work for only a potential $20K cash reward and so speculative an asset — but that remains to be seen.

Chunk #7 had an estimated potential savings of $100K. If no firm was willing to bid $50K or less, then the government cannot be assured that it can pay the judged cash reward out of in-year savings. In that case they may have to adjust the Taxpayer Equity Principle (TEP) to give the firms more than a 50% split. Let’s say that in extremis they offer firms all of the savings. If they still can find no firm that will bid $100K or less, then the Agile Share-in-Savings approach has failed for this project, and it’s impossible to finance the modernization purely out of the existing O&M budget.

It’s possible that firms will bid $0, counting on the future value of savings for all compensation, a situation hinted at in the micro-purchase program of 18F. This suggests that the Agency should adjust the Taxpayer Equity Principle in favor of the taxpayer and give the firms less than 50% of future savings.

The Agency realized an in-year savings of its O&M budget not of $37.5K, but twice that, or $75K. However, they just gave $15K to Alice Inc. They put the other half, $37.5K, back into their general budget, in accord with the Taxpayer Equity Principle. They had to pay $5K to the Assessor and $10K to the Refactoring Engineer. The net for the Agency (for this program) is a gain of $7.5K, which may be thought of as going into a “piggy bank” to finance further chunks in the future. This growing escrow increases vendor confidence of the ability to pay out FASiS Assets and cash rewards in coming years.

The U.S. Taxpayer is happy, because they they made (indirectly) $37.5K, and, by the Taxpayer Equity Principle, will get 1/2 the future savings for the next five years as well.

The Future Agile Share-in-Savings Asset (FASiSA) is a key innovation in the model, and requires careful consideration. The FASiSA was inspired by the Individual Transferrable Quota (ITQ) that’s used to make markets for future fish harvests. The key concept is that the total harvest is determined by biologists in order to obtain an ecological or economic good, such as to prevent the “Tragedy of Commons,” or overfishing. ITQs are legally transferrable securities, but that need not be the case for the FASiSA. It’s in theory enough to incent firms with a future revenue stream. Although a true market for such securities might ideally allow firms to “cash out” easily, firms can accomplish their own financing without such a market.

However, the FASiS Assets are fungible. That is, once awarded, the FASiSA is detached from the individual code chunk, and becomes attached to the future O&M budget in general. This is a key point because it means the FASiSA is less risky for an individual firm, because the risk of the payout now depends not on Chunk #7, but on ALL of the refactorings provided by all firms. In other words, the FASiSA payout will be determined by how well collectively the firms in the vendor pool decrease the operational expense of the project. Even if hindsight shows that Firm A always did a poor job and Firm B always did a good job, their FASiS Assets depend only upon what they were awarded and the future actual savings.

The future payout of the FASiSA is set by government authority. The Agency will determine the payout in future years, based on their ACTUAL, measured ability to decrease their operations and maintenance budget. Thus the FASiSA is not really a fraction of $10M per year so much as it’s a fraction of the obtained savings per year. This “pure” approach minimizes risk to the Agency. If something goes wrong (for example, the code proves less easy to maintain than the Assessor thought and therefore no savings accrue), then the Agency doesn’t have any financial obligation for that year.

All firms in the vendor pool are writing code against the same codebase. There is a systemic risk that these firms will not play together nicely at the level of software engineering. For example, one firm might attempt to use a data format convenient to them and inconvenient to other firms. However, the Legacy Refactoring Engineer and the Assessor will attempt to avoid this possibility. More powerfully, assuming that all firms in the pool end up owning significant FASiS Assets, all firms have a strong interest in maximizing the future payout of the assets. They will wish to compete in gaining the maximum cash rewards at the lowest bid and the maximum FASiSA awards, but they will not wish to sabotage the future value of those assets. This structure thus avoids what might be called the “Tragedy of Bad Cooperation.”

Naturally, firms will be skeptical that the government will fairly assess the future savings. This is a risk that they will no doubt price into their bids. We do not attempt to solve this problem, we merely suggest that over time a level of trust may be established.

A Spreadsheet Model

We’ve constructed an example modernization program as a spreadsheet. You may be able to copy this in order to play with the input cells, marked in blue. Unfortunately, this spreadsheet is a bit too wide, representing ten years, to be rendered in-line here. You may wish to the follow the link to the Google Sheet, and then use the “File->Download as” menu option to download it as a Microsoft Excel Spreadsheet or some other format so that you can edit the fields marked in blue to understand the model.

This spreadsheet makes the simplifying assumption that the Assessor precisely estimates the future savings. This will of course not exactly occur in practice; however, over the course of a ten-year modernization, we believe any mistakes the Assessor makes can be tolerated. Recall that we only pay out the FASiS Assets from actual savings against a baseline, and if no absolute savings are obtained, the government has a $0 obligation.

Note also that this spreadsheet attempts to characterize overall savings over time, and also the obligation of all extant FASiS Assets, which will be discussed in more detail below.

Advantages

The primary advantage and indeed the need for this relatively complicated approach is to minimize risk and outlay to the Agency. In this model, the $10K fee paid to the Legacy Refactoring Engineer and shortly thereafter the $5K fee to the Assessor is the only outlay that definitely must be fronted before any income is or savings are obtained. Except for this fee, it maintains the Actual Savings Only principle that asserts that Agencies pays out only a fraction of actual savings. Thus the Agile Share-in-Savings approach is perhaps the most strictly performance-based approach yet articulated.

The Agile Share-in-Savings approach frees-up capital that’s currently frozen into O&M budgets and allows it to be used to entice firms to take risk. Since the reward is potentially the savings across six years (current plus next five), companies have a large potential reward. Because of competition within a pool, no firm can walk away with a windfall. Because of the Taxpayer Equity Principle and the Actual Savings Only Principle, the government will pay out only this frozen capital, and will be guaranteed to return a fraction of it to the Taxpayer (indirectly).

In addition to simply being the only way to modernize a system financed out of only an O&M budget, it also overcomes the problem of not having to obligate a large amount of money to cover unfunded termination liability, a stated objection to previous share-in-savings attempts. The government must only obligate a changing fraction of its own O&M budget.

The second advantage is that this model conforms to modern software engineering best practices. This is the way a software firm would modernize their own legacy system, except that firms would tend to have a technical staff consisting of a higher ratio of employees to contractors than most government agencies can obtain.

Such software practices have evolved largely to decrease risk or at least to decrease the granularity of risk. Agile software methods don’t prevent people from making mistakes — but they force them to make small, recoverable mistakes rather than catastrophic fiascos.

As previously discussed, this approach encourages firms to compete on price while encouraging them to cooperate on engineering. The Independent Modularization Principle suggests that even if you stopped at an arbitrary point in the rewriting process, you would have a codebase that was easier to test and to maintain because there would be less specialized tribal knowledge and less vendor lock-in.

Finally, this approach gives the benefit of competition (in the bidding within the vendor pool) and cooperation. It seems unlikely that any firms can walk away with a windfall so long as the vendor pool of bidders is large enough. We hope that two principles we have articulated, the Actual Savings Only Principle and the Taxpayer Equity Principle, will convince government watchdog groups not to oppose experimenting with the Agile Share-in-Savings approach.

Potential Problems and Potential Solutions

Insufficient Reward

Perhaps the biggest risk to the Agile Share-in-Savings approach is simply that firms will choose not to participate. Of course, this risk is really a risk of wasted time, because if nobody participates, all that has been lost is the time taken to realize that.

Nonetheless, the readers might well doubt that Alice Inc. would actually be willing to hire and pay enough labor out of pocket for the speculative hope of $20K now plus future profit, which depends on several things going right:

1. They need to do a good job refactoring the chunk.
2. The Assessor needs to fairly recognize their good work.
3. The government must both realize a savings in future year and honestly pay it.

Although in our scenario the total possibility of $50K now (if they won the bid with that) plus a potential of as much as $250K (in the unlikely scenario of a 100% judgement) in the next five years might well motivate Alice Inc., but it might not.

If no firm were to bid, the government agency could then retreat from the Taxpayer Equity Principle, increasing the reward, as much as doubling the total possible reward to $600K, by effectively promising 100% of savings to firm. We recommend against this and believe that the government should never pay out more than 75% of the savings.

If the payout is increased to 75% of estimated savings, so that Chunk #7 is given a $75K in-year bonus and 75% payout ratio of future savings, the auction may still fail to attract any bids below the maximum.

In this case, we believe the agency has no choice but to appropriate a certain amount of money to the modernization effort. This could be gradually attached to each Chunk as an in-year cash bonus (never as part of the FASiS Asset). Presumably, there’s some amount of money to be paid out in the current year that would cause a firm to be willing to expend their labor to achieve a speculated payout by the Assessor. This would be what we have called a Hybrid Agile Share-in-Savings approach. Such a model still has the advantage of gradually rewriting the legacy code in a low-risk way conformant to modern software methodologies with firms competing for the work on a per-chunk basis.

Firm Size Risk

This approach favors large firms with the financial wherewithal to absorb risk today for future revenue. On the other hand, it favors small firms because it allows them to participate in projects 1/100 of the size in which they may have been previously competed, which a small team could never hope to win. For example, a five-engineer team could easily compete in a vendor pool and take on 1% chunks of the hypothetical CMS here, whereas no five-engineer team could expect to win a $50M modernization contract. It might, however, require small firms to use creative financing to swap future revenue for the ability to pay the bills today.

It’s easy to imagine a vendor intentionally populated by one of the set-aside special classes that the government defines such as an 8(a), Service-Disabled Veteran-Owned Small Business, and Historically Underutilized Business Zone. However, it might behoove the government to use a Hybrid Agile Share-in-Savings approach in such cases to assist firms in financing their day-to-day operations. Potential future rewards can easily be decreased to compensate for increased in-year awards if desirable.

Integration Risk

Through personal experience in both government and private industry, we believe it’s possible to fulfill the role of the Legacy Refactoring Engineer. However, performing that role is not simple. The Legacy Refactoring Engineer must have some specific abilities that aren’t trivial to find in a single person or small team:

1. Above all else, the ability to dive into an unknown, messy codebase they didn’t write in a language they may not be familiar with and make sense of it.
2. The ability to competently write an API and associated automated unit tests that more or less cover the functionality of the chunk in question.
3. The ability to document and/or directly communicate to the vendor pool the nature of both the chunk and the unit tests so as to not add uncertainty to their task, which they would surely price into their bids.
4. The ability to correctly discern a chunk that represents approximately 1% of the total problem. Small inaccuracies aren’t a problem, but systematic biases could in theory lead the agency to commit all possible future savings to firms before the majority of the entire code was actually rewritten. The government would still not have to pay too much due to the Actual Savings Only Principle, but the whole process would be distorted by such a bias.

We believe it’s now possible to find that talent within the federal government, but resources are thin and it’s only in the last few years that 18F, U.S. Digital Service, and the Presidential Innovation Fellows program offer this possibility beyond the small set of stalwart, overworked professional technologists that have always been in government. Like anything, though, we can imagine that the government will get better at this by building a community of practice over time.

An additional integration risk is that Code Quality Assessor will misjudge chunks, or that firms will vehemently disagree with their judgements. However, the Assessor will not be making one judgement only, but hopefully will be working on an ongoing basis — for example, making ten formal judgements in the first year. We can reasonably expect the judgements to stabilize over time, just as every umpire calls a few pitches wrong without being accused of overt bias for one team or another.

A final integration risk that, for example, 10% of the code is rewritten, but in the coming year it’s found that this does not translate into a 10% cost savings. This might occur due to poor formal judgement, or it might occur because the government cannot successfully negotiate a cost saving based on the cleaner, smaller code, even if all parties agree that the code is better.

Do not make the mistake of believing that these risks argue in favor of a huge monolithic rewrite. Even if you completely disagree with the Agile Share-in-Savings approach, you need only look at the track record of such rewrites and their embarrassing failure rates to understand that it’s worth working through any difficulties to use an agile approach rather than a monolithic approach.

Technical Miscommunications

It’s always possible that there will be technical miscommunications that could create fractious disagreements. For example, a firm might submit a solution that calls for the incorporation of a new library into the code. The Assessor, investigating the library, finds that although free and open source, its community of practice is not large enough to be considered a stable and secure piece of code to include. The Assessor thereby rejects the entire solution, leading the firm to bitterly complain about miscommunicated expectations.

It’s a generally accepted principle of software engineering that “Succinctness is Power.” That is, it’s almost always easier to maintain a 500-line module than a 5,000-line module. We expect the Assessor to make use of this observation, and furthermore to use any automated code-quality analysis tools (there are many) that they consider appropriate. In fact, we believe it’s imperative for the software industry as a whole to develop a functioning model of technical debt, which probably does not exist today.

However, in the end, code quality and clarity will always be a judgement call. We hope that in general this approach is less adversarial than monolithic software contracts in general, because “chunking” strongly suggest an ongoing relationship. The competitive nature of the vendor pool hopefully prevents cronyism and “wiring” of contracts.

Legal Risks

We recommend the government accept the slight legal risk exists that the government might have to obligate money to pay out its outstanding FASiS Assets, in the case that it shuts down the entire program, rather than asking firms to bear that risk. This money comes out of savings from the existing O&M budget, and if the government chose to, it could decrease its speed of modernization thereby decreasing its growth rate of exposure to FASiS Assets and the risk of program cancellation. Additionally, the savings building up over time could be escrowed against this risk. Thus the Agile Share-in-Savings approach offers several ways to largely avoid the historic issue of requiring the obligation of huge amounts to cover all expected savings upfront. To the extent that a legacy system is in no danger of cancellation within the next five years, this risk doesn’t exist. The example spreadsheet we have attached tracks an example of this obligation which changes over time. If a user copies this spreadsheet and plays with the input percentages, that will quickly get a feel for the how the Agency can minimize this obligation by adjusting the speed of the rewrite.

Because this system relies on judgements in various ways, it’s always open to legal challenges on a small scale. However, it seems to spread these challenges over both the time and budget of the agency, rather than risking them all at once, as happens in a performance dispute at the end of a gigantic monolithic rewrite.

Suitability to Non-Legacy Systems

The Agile Share-in-Savings approach makes sense when there’s a predictable future revenue (or savings) stream that can be monetized in this way. This article mostly discusses a working example of a legacy information technology system, because such systems have generally demonstrated their durable usefulness and have a predictable future O&M budget. However, there are other government systems to which this might be applied, such as those that more or less predictably generate revenue. Examples include the surplus material sale system of the General Services Administration and the park fee collection system of the Department of Interior.

However, in all cases this model only works if there’s a relatively definite means to judge the savings. For example, a stable legacy system has a well-established O&M budget that can be treated as a baseline to measure future savings against. If, however, Congress mandates drastic changes in the middle of the modernization process, then the “refactoring” gets convolved with the “enhancements,” making it difficult to fairly state what the actual savings are.

Note that government need not solely develop the standard for cost savings. Industry could participate in defining measures and other aspects of contract structure, so long as all is public and sufficient technical consultation within the government available.

Where to Begin?

As presented, the adoption of our Agile Share-in-Savings Model would require mastery of several important elements, most of which are relatively new to government, including SiS IT itself, even though it’s an old concept. As the saying goes, “big things have small beginnings.” In that spirit, we recommend starting lean by piloting a center of excellence team with the right staff and who is empowered to run well-designed experiments with willing vendors, learn from those tests, and to iterate on and eventually scale the model. There are sufficient authorities in place now to get started with elements of our model. No act of Congress is required yet. Let delivery inform policy.

In the end, perhaps all the features that we’ve proposed will be validated — or perhaps they will all be invalidated. Perhaps an entirely new model will be discovered. Regardless, something will be learned and progress will be made. After all, the reality of the situation is that the federal government is indeed facing an aging-systems crisis, and we need options for dealing with it.

Conclusion

This concludes our four-part series on bootstrapping the modernization of federal legacy systems through Agile Share-in-Savings contracting. At the very least, we hope that we presented a new model through which to think about applying the practice of share-in-savings contracting to information technology and software. We by no means claim to have all the answers nor to have thought of everything. Feedback is a gift, and we encourage and welcome your input so that, as a community, we can iterate on the construction of a model that solves a pressing public problem: the continued aging of a large number of federal IT systems that support many, many critical mission and public-service functions. This problem isn’t going to solve itself. But together, we can.