Turn the problem statement into an outline for possible solutions, framed as individual modules
2b. Modularization
This section will help you:
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.
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.
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.
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.
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.
Takeaways
Modularized software map with success criteria
High-level project budget
Further reading
