Let’s say you have a problem of how to get to work from your house in the suburbs to your office in the city. You look at your situation and you buy a car. The car provides the desired outcome of transportation to the office and back.
You do not have to specify the size of the engine, how much stopping power the brakes have to deliver, or the number of lumens its headlights put out. This is very much like agile procurement. You describe a preferred outcome that is important to you; everything else may change according to need or circumstance.
Rising citizen expectations and stretched government budgets are forcing a shift to agile procurement for officials. Traditional procurement models forced users to specify years in advance and in detailed form precisely what they want made before vendors decide whether they could fulfill those specifications at a reasonable profit. But requirements change along with users and failure rates were high, necessitating a change.
An article from Deloitte clarifies:
The Agile process combines design with development and user acceptance. In other words, the software’s final design emerges through a collaborative effort between developers and business users. So the traditional procurement approach, heavy on functional specifications written up front, isn’t consistent with the Agile approach.
[…]
Agile software development requires software buyers to rethink the role of the contract. Instead of serving as the ultimate blueprint for the projects—detailed specs, precise price, firm deadlines—the contract becomes a guide for structuring the relationship between the government agency and the vendor. The shift in mind-set is profound. The agency is no longer looking to buy a “thing”—in this case a new software system. Instead, the agency is entering a relationship to jointly design and build a new software system.
Governance blog GovInsider points out a singular benefit of being agile:
Agile procurement helps encourage innovation, by shifting away from the traditional approach where full-scoped project details are spelled out from the start. Instead, a concise one page summary will do. “We simply say, ‘Here is our problem, we want the most brilliant solutions out there, and then we are going to let you fly,’”, Aneesh Chopra, former CTO of the United States told GovTech Magazine. “We’d still protect the integrity of the public dollar, but we’d figure out a way to let the private sector be inventive.”
The shift to agile procurement will demand a different approach from both contractors and the government. This new approach will demand a lot of trust between the two parties particularly in reference to the costs of the project. There can be no fixed price for a project whose contours were not specified beforehand. Equally, the government must also be protected from cost inflation. Incremental pricing may help here as the contract may be paid as certain short-term milestones are achieved.
One last bit of advice from Deloitte:
More than a well-written contract or massive spec document, for Agile to succeed there must be a leader at the agency with a vision for what the application is going to do: Whom does the software support? What is the business challenge being addressed? How will data enter and leave the system? The Agile process turns this vision into working software.
