![icon.goal](img/icon-goal-24@2x.png)
Turn the problem statement into an outline for possible solutions, framed as individual modules
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
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.
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.
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.
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.
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
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.
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:
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”
Modularized software map with success criteria