Managing modular contracts
What is Modular Procurement?
Modular procurement is a procurement model that breaks what would traditionally be a large, monolithic contract into several shorter-term, lower dollar amount contracts. When combined with human-centered and agile practices, it can mean allowing those who use your services to use portions of the new software faster.
Modular procurement makes it easier to manage software development by segmenting risk. This acquisition strategy permits isolated failure in one unit of many units, rather than letting it impact the entire project. Because each project is smaller, they are easier to comprehend and manage, making problems and risks smaller so you can recognize and resolve them more easily.
As the government needs to more closely monitor the performance of smaller contracts they can help remedy problems to avoid cost overlays and drawn out schedules.
In contrast, the vast majority of larger projects are overbudget or failing. The Standish Group found that:
Of 3,555 projects from 2003 to 2012 that had labor costs of at least $10 million, only 6.4% were successful. The Standish data showed that 52% of the large projects were “challenged,” meaning they were over budget, behind schedule or didn’t meet user expectations. The remaining 41.4% were failures — they were either abandoned or started anew from scratch.
Shorter contracts will reduce the risk of factors beyond your control.
Planning work for a successful six-month to twelve-month contract is easier than planning a successful six-year contract. Modular contracting allows you to craft procurements that set out expectations for segments of work rather than scope out every contingency that could happen over the life of the product. Longer contracts also don’t easily account for inevitable changes in leadership, legislative and other policy constraints or emerging technologies.
To do this modular procurement should model iterative software development practices. This means that you are continuously improving both the product and your process and delivering some customer value as soon as possible. Building a Minimal Viable Product (MVP) and learning from it ultimately results in a better product than the traditional approach of trying to scope out what an complex product without validated assumptions looks like all at once.
Code consistency and compatibility reduces vendor lock-in.
There are well-documented, standardized software development practices that can be standardized across vendors, and tools to enforce those. These practices can be incorporated into the contract via the Quality Assurance Surveillance Plan. The following practices facilitate faster on-boarding of new development teams.
By adopting a “programming style guide” and an automated style checking tool (known as a “linter”), your vendors can ensure the code style is consistent. By adopting other automated quality-checking tools (examples include Code Climate and HoundCI), your vendors can avoid other poor code quality practices. Because the code is open source, vendors can see the code they have to integrate with. By having automated integration and unit tests, your vendors can identify and fix code that breaks or doesn’t integrate as soon as it’s written.
On-boarding vendors is more manageable when projects are modular.
One of the major burdens of on-boarding is the time for a vendor to understand the entirety of a project. By reducing the size of each project and simplifying the specs, the time required to onboard vendors can be reduced substantially. This makes it manageable to onboard several vendors over the course of a complex project, and reduces the risk.
In modular contracting, however, there will be some amount of system architecture and integration planning by the government to ensure that vendors understand where certain technical and business decisions will impact their portion of the work. Or why previous parts of code that they may interact with are structured that way.
In particular, with open source software development include clauses in the statement of work that require vendors to make back-ward compatible changes when work developed in service of a particular module should impact the entire project.
Consider pre-qualified user-centered vendor pools can help speed up modular procurement in the long run.
Agile vendor pools are groups of vendors that have been pre-qualified to work on modular procurements.
During the selection process, the vendor pool is asked to provide proof of their abilities through working code, rather than extensive documentation. That process can include:
- Developing a programming challenge for the vendor community (for example, the challenge for Mississippi’s agile vendor pool was to build a prototype of a website that lets parents or caseworkers search for child care providers in their vicinity).
- Defining a short period of time (days, not weeks) to build a prototype.
- Asking for a link to the working prototype as part of their proposal, as well as a link to the public source code.
- Evaluating the proposals based on adherence to coding and design best practices, proof they followed an agile methodology, and evidence of their user research.
- Selecting the best-performing companies for your pool. We recommend starting with a smaller number of companies, perhaps 8 to 10. This is a manageable number, and with a defined on and off-ramp process, the size of the pool can be modified as the amount of work that can be managed increases.
- Once your pool is created, you can write a “task order” (specific language varies from federal to state to local governments), or an RFP that only goes out to the vendors on the pool. Since they are all pre-qualified, you know they are all capable of doing the work, which lets you skip that stage of the evaluations for each subsequent RFP.