1d. Market research

This section will help you:

Become familiar with the landscape of potential solutions

Engage responsibly with experts, the civic tech community, and vendors

Circulate the problem statement

Establish internal and external benchmarks

Common challenges

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

Legacy systems

Most city governments work with a patchwork of digital systems. That means they need to simultaneously use, maintain, and modernize legacy systems, as they consider new software that may or may not be compatible.

Lack of attention to non-commercial solutions

License fees for off-the-shelf products are predictable, and therefore easy to budget. In-house development and open source software, on the other hand, are uncertain. However, they often provide competitive functionality, and give you direct control over costs, end user pricing (if applicable), data, and governance.

Hesitancy to engage directly with vendors

Civil servants feel that engaging with vendors in advance of a project 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.

Recommended actions

1. Scanning the landscape

Become familiar with the world of experts, civic tech enthusiasts and vendors related to your project. And let them become familiar with you! If you are willing to openly discuss the problem you are trying to solve, you will hear expert opinions on existing or potential solutions—potentially saving you time and effort throughout the procurement process or pointing you to the best solution.

Peer jurisdictions often face the same set of challenges

Whether in communicating with constituents, HR, or traffic management, one of your peers may have solved the same problem you’re facing.

A rich ecosystem of vendors build and maintain software

Broadly speaking, there are several types of custom software development companies: enterprise, big business, mid-market, small, freelance, off-shore. Supporting the local ecosystem of software service providers may align with your broader organizational goals for economic development.

There is a wide variety of open source software solutions that rival the functionality of proprietary software

Visit the Github page and get a sense of how active the community of contributors and stewards is, paying particular attention to how recent the activity is.

Put out a call for ideas, or Issue a Request for Information (RFI)

informally, in the civic tech community, or formally, through city channels

Engage with peer jurisdictions

Similar public sector organizations that have addressed the same problem statement.

Host an event

Invite community groups, entrepreneurs, students and vendors.

Reach out to the academic sector

…?

This is an opportunity for creativity!

What if there is only one commercially available software solution?

Competition is a good thing, but in rare cases only one vendor can deliver the solution—allowing you to bypass the open RFP. National Digital Service Agencies often provide resources to guide rationale for sole-sourcing—you will have to develop full documentation showing that only one solution exists, and procure it through a sole-source contract.

2. Setting internal and external benchmarks

Before you start writing an RFP, it’s important to establish and document internal and external benchmarks. These outline similar projects that have happened within your organization, and similar projects done by peer jurisdictions.

Ask about prior projects within your organization

What have prior software projects cost to procure and to maintain? Have they been successful? What can you learn from their process?

Audit other cities and other businesses

What do they use to solve the same problem? Is their software open source?

Research IT standards

What are the industry best practices? What are the most common features? What are the most common software architectures and licensing models?

3. Mitigating downstream contract issues

As you analyze available solutions in the market, be critical and cautious of long-term issues that arise due to a specific business model, a general approach to ownership, or monetization, software performance, or contract details. This will influence your choice of strategy.

Research the following aspects of the available software options.

Ownership: Proprietary software; Dependence on proprietary systems (like databases); Data use and ownership; Software ownership

Security: Vulnerability; Risk; Responsibility

Interoperability: APIs; Compatibility with existing technical infrastructure

Actual use: Software is licensed per “seat” (users with software access), and may have minimum fees. Work to ensure only people who actually use the software are licensed.

Maintenance: Regular software updating; (Re)integration with new digital infrastructure; Ongoing user support

Software licensing and revenue models

There are two main categories of software licenses: proprietary and open source.

A proprietary license grants an end user the right to use software, typically for a fee. Users are prohibited from modifying, copying, sub-licensing or distributing the software. Proprietary software is designed to prevent users from accessing the source code.

An open source license grants anyone the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose (often with attribution). The underlying code (“source code”) is available to end users.

Software development companies have adopted various models for generating revenue. Most revenue models apply to software that is under a proprietary license.

One-time purchase: A license can be used by a single user or a group of users. This often applies to software that is hosted locally.

Subscription: Unlike licensing, a user receives access to the software by paying a subscription fee on a monthly/annual basis.

Pay-per-use: This pricing tactic is mostly used by different cloud-based products and services that charge you for the computing powers/memory/resources/time used.

Freemium: A user may access a basic product for free, but will be charged for additional functions, services, bonuses, plugins, or extensions.

Hybrid pricing: Elements of several different revenue models may be combined into a hybrid pricing plan. For example, a freemium plan might become a pay-per-use tiered plan after passing some limit in computation or resources.

Service delivery: The client pays for the time and expertise needed to create, customize or implement software—not the software itself. This is most common with open source software.

4. Creating a market analysis report

Map out the landscape of existing software (open source or proprietary) that can potentially address your problem statement, as well as the vendor ecosystem who could potentially build custom software or adapt open source software to address your problem statement. You will then analyze the landscape using a variety of indicators.

Document the landscape

Include software that could address your problem statement. Document the vendors who could build custom software to address your problem statement—whether that means adapting open source software or building new software from scratch.

Analyze the landscape scan a clear, neutral and objective way

Market maturity: number and size of potential vendors

Commercial readiness: reliability of solutions

Comparison of software solutions: consider their pricing models, feature sets, data management and ownership, integrations, compatibilities, etc.

Open source software: consider how active the community is, feature sets, integrations, compatibilities, and whether the codebase complies with the Standard for Public Code.

Resources provided by higher levels of government: Federal agencies like the US GSA, Data.Gov, the Canadian Digital Service maintain software libraries.

Takeaways

Internal and external benchmarks

Market analysis report(including a list of available software, vendors, and business models)

Process code for software procurement