← RFP Writing Assessment phase →

6. Agile development planning and resourcing

Read this if you are building software in-house. For all other procurement approaches, skip ahead to the Assessment phase.

Diagram showing who should read step 6

Goals

To turn the problem statement into objective and fair outcomes and evaluation criteria, incorporating insights from market research and benchmarking exercises.
To incorporate departmental and municipal priorities into the criteria.
To develop an objective evaluation framework.
To lay the foundations for an effective internal development process, including adequate resources for software development and maintenance.
To use modular budgeting, awarding small contracts based on incremental performance reviews.

Actions

Initial planning for an agile development project

The best practice for contemporary software development is “agile development.” This is a project planning and execution method that emphasizes creativity, reduces risk, and biases toward results. If you are building software in-house or procuring custom development, you will start with a rough, high-level pre-plan. This initial planning and resourcing will lay a foundation for collaborating with a vendor or beginning your own process of developing software in-house.

Write a simple, clear description of what the solution is, and how it addresses the problem statement.
List all of the different user groups who will interact with the solution.
List the features that will make the solution work. Categorize the list into “Must-have” and “Nice-to-have” features.

Resourcing an agile development project

Software development requires significant technical expertise, particularly for applications that perform essential services and need to be secure and dependable. Some cities have IT departments that can execute such projects in-house. Others will issue an RFP to find a vendor that can build custom software, or to find a vendor that can do a custom implementation of existing open source software. In all cases, it is important to appropriately resource the project so that the process is collaborative and leads to the right solution.

Name the product owner, teams, and other stakeholders involved using the following tags:Decision-maker, Accountable, Responsible, Consulted, Informed.
Set a reasonable timeline with sufficient space for iteration and exploration.
Make sure that there are milestones along the way. Set meetings when all associated stakeholders can review the progress to date and provide feedback (aligning with DevOps and modular budget milestones).

Modularization and modular budgeting

Monolithic, long-term software plans (the “waterfall” approach) are risky, because requirements change along the way, and the solution you initially planned may not be the best one. Agile development resolves that problem, because planning happens continuously, in response to what you are building and learning. Agile development produces discrete modules that are continuously deployed, which means you will see functional software much sooner. Agile development projects are well-suited for modular budgeting. That means you can focus on securing a budget for specific deliverables that can stand on their own. A deliverable might require one or more sprints.

Establish an overarching plan for the software package and create a rough map of the individual modules. This should include features for each module, an interoperability plan, and a general technical architecture.
Identify one or two modules that you will start with. Scope the features of those modules.
Define evaluation criteria for each of the initial modules.
Create a budget for the initial modules that accounts for its complexity (measured as engineers’ time). This will require a working technical knowledge of the standard software development process, and familiarity with the project at hand – work with the IT department and get feedback from engineers themselves.
At the end of the initial sprint, the module should be deployed into the city’s actual working environment (see DevOps below).
Each module should be rigorously evaluated.
- Does the module meet KPIs? Does it address a user journey that is relevant to the problem statement?
- Is the product logical and usable for the end user?
- Does the product integrate with the city’s existing digital environment?
- Did the process align with your values and qualitative objectives?

Common challenges

Inadequate resources

Software projects require sufficient staff time and expertise. It is particularly important to account for the open exploration and iterative revision that is a core principle of agile development.

Difficulty in migrating

Most projects will require a transition from a legacy system to a new system. This can be particularly challenging in the case of essential services that cannot experience a gap in performance.

Scope creep

Development can go over time and over budget if teams include too many features and do not effectively address the core problem statement.

Over-specification

Creating highly detailed plans for the full development process (in terms of feature specifications and process) can make it challenging to address problems that arise, and stifle the development of unexpected and superior solutions.

Lack of communication and collaboration

Not involving technical experts in the overall project plan, or not giving them enough autonomy to scope and plan sprints can foster poor working relationships or result in poor-quality outcomes.