Process code for software procurement

2b. Modularization

This section will help you:


Turn the problem statement into an outline for possible solutions, framed as individual modules


Use modular budgeting to support Agile development, encourage creative solutioning and remain in control of cost and quality

Common challenges

You may encounter these frictions as you do the work of modularization. These are challenges the Recommended actions are designed to solve, or that may arise as you take those actions.

Monolithic contracts

Contracts for long-term waterfall-style software development are risky. Requirements change and good ideas emerge over the course of a project, but firm-fixed-price contracts lock you into buying what you scoped up front.

Bid splitting

Modularization is a fundamental premise in contemporary software development—it’s how agile works. However, modularization can look a lot like bid splitting—which is a classic example of procurement fraud.

Recommended actions

1. Conducting an initial “design studio” workshop

Writing an RFP is about outlining a space for possible solutions to the problem statement. That requires some creativity! Spend some time going through an open-ended design studio.

Union Group 194 Line 48

Use the problem statement as your guide

What are the outcomes you hope this solution will generate? Don’t focus on the solution itself, focus on what the user will be able to do, and how their workflow will be improved.


Create a rough map of individual elements of the solution space

Tightly scope each module. Each should be able to stand on its own, and also interface with other components.

2. Modular Budgeting
In a contemporary Agile DevOps approach, planning, building, integrating and evaluating happen continuously. Discrete components (modules) are continuously developed and deployed.
Your RFP must reflect this modular approach. Do this by writing the RFP for the full project (resulting in an umbrella contract), allowing the details about each module (goals, evaluation criteria, timeline, budget) to be specified and contracted during development. That means each module will be scoped, contracted, and evaluated separately.
Union Group 194 Line 48

The vendor should provide a working demonstration at the end of each development sprint

That means the module will be deployed into the city’s technical and operational environment, giving you and the end users a chance to rigorously evaluate the work. If a vendor is under-performing, you can transition to another vendor quickly and easily.

Union Group 194 Line 48

Consider that individual pieces might use different development strategies

For instance, some may be OSS, others may be contracted.


Establish an overarching plan for the software

Include an overall budget.

Create a rough budget for each module

This should be based on its complexity (measured as engineers’ time). it will require working technical knowledge of the standard development process, and familiarity with the project at hand.

Why use modular budgeting? 
Modular budgeting is a great way to get actively involved in agile development, and maintain a degree of control over the project process and outcome.
Requires you to scope and evaluate each module. You work closely with the development team to plan each sprint and evaluate the outcome once it’s finished.
Lets you control the risk that vendors under-perform. You only pay for short sprints that produce discrete deliverables, which can stand on their own. If you need to break the umbrella contract, you have the modules that have been built, and you can find another vendor to carry on the project.
Reduces vendor lock-in. Vendors have less incentive to use artificial “lock-in” strategies, and focus instead on quality. You are in control if there are quality issues.

4. Working within municipal budget thresholds

Consider the overall budget for the umbrella contract, which includes rough budgets for each module. The project may not need to go out for a full RFP.

Union Group 194 Line 48

As an example, many US cities use the following thresholds:

Discretionary (<$10k) procurable through sound business practices
Contracted ($10–50k) procurable with a written quote contract or service order or sole-source
Full bid (>$50k) procurable with an Invitation for Bid (IFB) or Request for Proposals (RFP)

Based on market analysis and modularization strategy, consider your RFP’s scope

Should it include the full software, or is it better to start with a small, discrete module that stands on its own and helps you plan the rest of the project?


Be careful of “bid splitting”

Modular budgeting can look a lot like bid splitting. The Association of Certified Fraud Examiners defines bid splitting as “Employee splits large contracts into smaller contracts to avoid the scrutiny required for larger contracts.” You can avoid this by:
Working in the open, and meeting proactively with the legal team.
Clarifying that each module is additive, contributing to a larger whole.
Ensuring that the contract amount is a legitimate reflection of the work involved, as opposed to targeting just under a procurement threshold.
Ensuring that RFPs are competitive when needed.
gear 2 arrow 2

Modularized software map with success criteria

gear 2 arrow 2
High-level project budget