The federal government spends billions of dollars on IT contracts, but its acquisition system has not kept up with the changing pace of technology. The government still manages vendors, much as it always has, and relies on the Federal Acquisition Regulation (FAR) for guidance in the regulation and legalities of contracting. However, acquisition processes have evolved beyond the FAR, including an agile approach to contracting.
Waterfall vs. Agile
Waterfall offers a predictive approach, and requires a significant time investment in producing a plan, thereby making the plan the most valuable asset. The project’s scope is fixed, and the agency creates a comprehensive requirements document although agency officials know little about what the work will ultimately entail. Using insufficient data on the required resources and realistic timelines, the agency can only estimate costs and deadlines. The deadlines can incentivize developers to deliver products before they are really ready, causing quality to suffer.
Read my white paper "Federal contracts for agile delivery" for a deep dive into this topic.
Agile, on the other hand, brings an adaptive, value-driven approach, not a pre-developed plan. With a dynamic project scope, it involves ongoing revisions to plans as the project progresses. The project doesn’t require a big, up-front requirements document, because agile welcomes change, even late in development. Cost and time are predictable, as agile operates in fixed duration iterations. Quality is built in because the customer works hand in hand with the team, approving all the little pieces.
Can a firm fixed-price contract be agile?
Agile software development principles hold that collaborating with customers is preferable over negotiating contracts. However, in the government, contracts are unavoidable.
Procurement offices in federal agencies encourage firm fixed-price (FFP) contracts. While this may not seem conducive to Agile methodology, in fact, an FFP contract can be very agile if the agency sets the correct parameters. Use a statement of objectives to set a high level scope, then fix the time and spend based on number of teams and length of the periods of performance.
In traditional procurement, the contract includes prices, delivery and system performance. In Agile procurement, the final product emerges through a joint effort during the process. Contract management offers the key to success, not the contract itself. Government procurement officials don’t typically provide ongoing input and support through contract administration, which creates a gap. The business owner and procurement official must regularly engage throughout the process. Agile calls for frequent demonstrations that share progress and challenges with the stakeholders. Hands-on involvement is critical to monitor progress and avoid last minute surprises.
The federal government has long focused on minimizing risk, sometimes at the expense of delivery. This mindset impedes Agile implementation. The long list of “supplier shall” statements, typical of government contracts, works best for well-defined procurements. For innovative products such as software development, the process gives only the illusion of control.
I worked at the IRS for 10 years as a buyer of services and was challenged when the procurement office would only let me do FFP contracts. I continuously looked for ways to make procurement more agile and finally found one: hybrid contracts. In a hybrid contract, at least 51% of the work was on an FFP basis and the remainder—49% or less—could be used for ad hoc task orders.
I aligned the task orders with quarterly periods of performance, which had a fixed amount of funding per product team. This approach required establishing a “not to exceed” threshold, which kept the budget and expenditures predictable for the agency while allowing the product team freedom to innovate within that boundary. This allowed me to put the longer term projects under FFP and define the shorter term projects through separate task orders for shorter durations.
Since then, the Federal Acquisition Institute has put new guidance in place for Agile contracting, and are actively working on policies and procedures to assist government agencies with this challenge. They offer free training for federal employees, and have publicly available documents and videos available on their website.
Naturally iterative contract types
Some vehicles, such as a blanket purchase agreements (BPA) and indefinite delivery/indefinite quantity (IDIQ) contracts, naturally align with iterative delivery. Both vehicles present a high-level statement of services or needs and allow for task orders to be issued against them. These task orders supply a detailed scope of work.
Agile federal programs can issue monthly task orders that define the scope of the project’s iterations each month. Save some time by using a template for each task order and update the scope section of each task order, but the rest of the task order should follow the template.
The ability to stop writing task orders when the results are subpar is also an advantage of this model. In federal contracting, it can be difficult to terminate a contract or agreement but it is not nearly as difficult to stop issuing task orders. These vehicles allow the clients to control the work and contracts based on the results the vendors or contractors are delivering.
Shorter contracts will reduce risk factors
By breaking up a larger procurement, your team can isolate failure into a small piece of the system, rather than letting it impact the entire project. Modular contracting allows you to craft procurements that set out expectations for segments of work, rather than unrealistically and impractically scope out every contingency that could happen over the life of the product.
However, managing many smaller contracts increases administrative burden. It requires a dedicated program management team to coordinate various teams. While this may seem like more work up front, it allows the program office to intervene earlier, when called for, and be more flexible. Many government offices could benefit from shifting their mindset and requiring training to handle this type of managerial complexity.
Successful modular procurement should model Agile and iterative software development practices by continuously improving both the product, the acquisition process and the software development process to get value to your users as soon as possible. Building a Minimal Viable Product (MVP) to test initial assumptions will lead to a better result than deploying an untested product developed with no input from users.
Since modular contracting requires the government to conceptually prioritize the most important piece of the project, it encourages faster delivery of the software that is most important or fundamental to the success of the broader effort. Instead of waiting for an entire large piece of software, the government can pursue deploying the first software module.
This provides the added benefit of helping your team pave the way for the security and compliance processes of future modules. Once those checks are passed, your users get to use your software; you deliver value on your mission and build your stakeholder’s confidence that you are effective in delivering software.
The goals of the Agile contracting approach in government
In order to transform contracts to be Lean-Agile, both parties must have a common set of goals that can be used to guide the negotiations. The contract should outline how the two parties will work together to foster cooperation, open communications, trust and transparency. It should address the risk of cost and schedule overruns and underruns through terms where both parties share the pain when the plan fails, and the gain if the contractor delivers the solution sooner or at a lower cost than expected. Finally, the parties should scour the contract for any process, deliverable or other element that does not add value to the solution or causes waste and delay.
Conclusion
Although government procurement hasn’t caught up to the Agile world, the FAR and its regulations can still be used to deliver with an Agile framework successfully. CGI’s Agile Center of Excellence can help bridge these gaps and work with government agencies to bridge these contracting gaps, deliver value early and often and save taxpayer dollars.