← Discovery research and problem statement Strategic analysis →

3. Market research

Diagram showing who should read step 3

Read this regardless of your procurement approach.

Goals

To become familiar with the problem and the landscape of potential solutions.
To engage responsibly with experts, civic tech community, and the vendor pool.
To circulate the problem statement to experts.
To establish internal and external benchmarks.

Actions

Scanning the landscape

Become familiar with the world of experts, civic tech enthusiasts and vendors. And let them become familiar with you! Discuss the problems you are trying to solve, and hear their thoughts on existing or potential solutions.

Market research and neutral market analysis of existing commercial solutions
Look at how other cities have addressed the same / similar problems
Call for ideas (informally, in the civic tech community)
Issue a Request for Information (RFI) (formally, through city channels)
Host an event related to the problem and invite community groups and vendors
Reach out to the academic sector
…? (this is an opportunity for creativity!)

Identifying types of vendors

Broadly speaking, there are types of custom software development companies. These are: Enterprise, Big Business, Mid-Market, Small, Freelance, Off-shore.

Explore the market in each of these categories.

Setting internal and external benchmarks

Become familiar with peers and precedents. Ifother cities or organizations have already solved the problem, consider licensing or partnership. If other cities need to solve the same problem, consider pooling resources in a bilateral agreement.

What have prior software projects cost (to procure and to maintain)? Have they been successful?
What do other cities use to solve the same problem? Is their software open source?
What do businesses use to solve the same problem?

Creating a market analysis report

Document what you find, in a clear, neutral and objective way.

Market maturity (number and size of potential providers)
Commercial readiness (reliability of solutions)
Number of comparable software solutions, their business models and approaches.
Consult libraries of Open Source Software (OSS) and resources provided by higher levels of government (e.g. the US GSA, Data.Gov, the Canadian Digital Service)

Knowing who can deliver

In some cases, there is only one vendor that can deliver the required solution – but those cases are rare. In general, competition is a good thing for RFPs. The Association of Certified Fraud Examiners has good resources to guide your rationale for sole-sourcing.

Identify the landscape of vendors who could fulfill the project needs you’ve documented.

Common challenges

Lack of internal consistency and digital integration

Most city governments work with a patchwork of systems. That means they need to use, maintain, and modernize legacy systems simultaneously.

Hesitancy to engage directly with vendors

Civil servants feel that engaging with vendors is dangerous. It isn’t. Get to know the local and international software community. Become familiar with certain companies you respect. Be actively involved and ask questions.

Insufficient communications between cities

Civil servants rarely engage with peers (adjacent municipalities or ones that have key commonalities). By discussing mutual challenges, you might find existing solutions, receive recommendations, or glean best practices.