Modular contracting is all the rage now. It promises to reduce risk, add flexibility, and deliver great software, faster. But merely breaking a $500 million procurement into smaller procurements isn’t going to solve your problem. Any complex project contains a lot of uncertainty. To be successful, your program needs to be responsive to what you learn as you go and update the direction based on what is discovered. Using multiple, small contracts does not necessarily guarantee this result, but you can build better products and get better at incorporating new information as you go by:
- Using short option periods instead of independent contracts, and
- Fluidly moving between the product phases of discovery, scoping, prototyping and build-out.
The pitfalls of multiple small contracts
In theory, multiple small contracts can reduce your risk by limiting the overall exposure if a contract goes bad. Small contracts are essentially a tourniquet, used to stop the bleeding. But some of the downsides are:
- Short performance periods (3-9 months) favor companies with sophisticated proposal writing shops and the ability to acquire bodies quickly, rather than excellence in delivery
- You can’t stay with a vendor you like if it’s going well and have to go through the solicitation process again
- Recruiting & retaining quality people for short projects is more difficult
- You must have your own product strategy capacity (or borrow from USDS’ or 18F’s)
- “Modules” may be unmaintained or not fully integrated into the larger project
- Multiple contractors may not work well together or collaborate
How can we get the purported benefit of modular contracting with fewer downsides?
1 contract - 6 month option periods
Once a contract is awarded, it still needs constant, competitive pressure to ensure a high quality work product throughout the period of performance. If there isn’t enough competitive pressure or the contract is going poorly, you need to have natural exit ramps to easily end the engagement. Using a longer term contract (2-3 years) broken into 6-month base and option periods gives you natural exit ramps throughout the lifetime of the contract.
To really take advantage of the option periods and maintain competitive pressure, you must always be solicitation ready. Just like the strongest bargaining position is being willing to walk away, the threat of competition doesn’t exist unless you are ready to recompete the contract at a moment’s notice. Every quarter, you should revisit your statement of work and update it to reflect what you’ve learned so far about your product. Ask the current vendor, what has changed for them? What have they learned since the last quarter? Keep this updated and ready to go so that you’re not caught flat-footed when you need to make a change.
The phases of modular contracting
What does a contract with 6-month options look like in practice?
Start with discovery
Your base period should start with a discovery phase before anything is built. The discovery phase includes research with users, stakeholders, and more. This phase is where you learn about what users need. If you’ve already done this, you can skip right to building.
Scope products and draft product strategy
Product “modules” that are developed independently need to be well-scoped. “Well-scoped” means that the boundaries of the module are clear, its tasks can be executed with minimal coordination, and a small team (fewer than, roughly, 15) can make sustained progress on it. This phase is where you group the user needs into manageable and prioritized chunks. This is also where you make your first attempt to chart the course from here to your end state. In other words, this is your product strategy. You’ll need to revise this regularly as you learn about your users, complicating factors, and the rest of the landscape.
Prototyping and validation
If you’ve already finished discovery and scoping, the rest of your base period is for prototyping, validation, and build out. This is where you build something extremely basic just to validate that you’re meeting the user needs you think you’re meeting. Sometimes this is called a Minimum Viable Product (MVP). In government, this term is often overloaded to mean a functioning product for a first release, but its true purpose is to be just good enough to validate some assumptions about how users want to engage with the product. The MVP is there to help you course correct as early as possible when your own vision doesn’t align with the user needs.
Prototyping is also a good chance to test out some basic technical assumptions, such as how easy it is to connect to a legacy system, or migrate data from one environment to another. After you’ve spent the first six months researching, prototyping, and testing, you’re in a much better position to know how to proceed forward. At this point, there are two options: exercise the option and continue building, or go in another direction such as a recompete, or maybe do nothing at all. Sometimes, what you learn in this first six months is that you’re building the wrong thing entirely.
Product build
This phase is for executing on the products while maintaining focus. This could be right at the beginning of your contract if you’ve already done discovery, or it might be whenever you’ve done enough prototyping and validation to be confident in what you will build. You should continue to test with users, validate as you go, and iterate, but when new major needs surface, break them off into a new discovery phase and repeat the process, as shown here. Or if you’re limited by your capacity, make a conscious decision to pivot to something else, but don’t try to cram everything into an ever expanding scope.
Limit the number of concurrent products/modules
As you build and scale your project, you can’t reasonably expect to have more than a few product teams doing build-outs for the same larger project. Even if the scope of your project is huge, you’ll get more done, faster, with fewer, focused teams. More teams will add to the churn, and each addition will reduce the efficiency and velocity of all the other teams. More coordination and overhead is required for all of the teams, and your product owners and program support staff become overwhelmed. Don’t be tempted to add teams just to use up money from the current year – you can use the new working capital funds, that are designated explicitly for legacy replacement and migration, to hold these funds. Take a page out of the Kanban book and set a “work in progress” limit on your program. Although it sounds counterintuitive, sometimes you have to go slow to go fast.
Modular contracting doesn’t just mean that you break one procurement into several pieces. You can take a modular approach with a single contract divided up into natural break points. Ad Hoc has had success using this approach with our work on both HealthCare.gov and the Quality Payment Program. As long as you stay “solicitation ready” and take an iterative approach to defining and developing your project, you can get the benefits of modular contracting without the additional overhead of several small contracts.
