1e. Strategic analysis

This section will help you:

Evaluate the total cost of owning software in four different scenarios

Mitigate downstream contracting issues (e.g. vendor lock-in)

Common challenges

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

Siloed budgeting and ownership

Products are typically paid for and managed by a single department with its own budget. However, a good software procurement, development process, and ongoing maintenance will draw on several different business units. Furthermore, modular software should (at minimum) be interoperable with systems across the city.

Hesitancy to procure solutions that do not offer conventional support

Customer service and support is a main feature of service contracts. The lack of conventional support channels is a common concern associated with open source software. In the previous step, you evaluated the extent to which the community is actively maintaining open source software. If it is not active, you can maintain in-house, or contract a vendor for maintenance. That will require a shift in your staffing and budgeting. Organizations like the Foundation for Public Code can help—they exist to help steward and maintain open source software.

Lack of familiarity with technical possibility

Civil servants are not well informed about the state of the art (what is technically possible and impossible, what it takes to build and maintain software, and how data, privacy and ownership should be managed). Up front capacity building and market analysis should fill this gap, but you can also hire independent experts to support your strategic analysis.

At the end of this page you will choose one of the following approaches:

Purchase existing

Get software off the shelf

Customize OSS

Contract a vendor to adapt open source software

Custom software

Contract a vendor to build software

Build in-house

Build software (or adapt OSS) in-house

Recommended actions

1. Performing a Total Cost of Ownership (Licensing) analysis

Software ownership can take many different forms, and each will have its own cost distribution. If your market research (from the previous step) revealed one or more commercially available software solutions or open source software solutions, you will prepare a Total Cost of Ownership (TCO) analysis for each viable software option.

Perform a TCO (Licensing) analysis

Acquisition: including all costs of the procurement process and change management (if applicable)

Direct: the “sticker price” of the solution (annual license or perpetual contract)

Adaptation: cost of creating a custom instance (in the case of open source software)

Integration: cost to integrate the software with existing digital infrastructures in use at the city (in terms of staff time and any software or database costs)

Operating: including annual fees, per-user cost, and insurance

Future customization: also known as work orders, these arise when the city’s needs, processes, or underlying digital infrastructure changes in the future

Disposal: which may include removal of the installation, clean-up costs or legal fees

2. Performing a Total Cost of Ownership (Building) analysis

If your research did not reveal commercially available solutions, consider building custom software. This can be built in-house (if you have staff with sufficient development capabilities, or budget to hire), or you can contract a vendor to develop custom software. In order to weigh these options, you should perform a TCO (Building) analysis.

Perform a TCO (Building) analysis

Initial design: including staff time and external consultants for planning the agile development process, and accounting for repurposing open source software

Staff salary: for software development, change management and ongoing maintenance (including cost of contributing back to the open source community)

Integration: cost for integrating with existing digital infrastructure at the city (in terms of staff time and any software or database costs)

Consider the value of building (and sharing) software

If your organization has staff with sufficient software development capabilities, consider building in-house. Although it takes more effort up front, there are long-term benefits (see Section 3, next). Even if commercial options are available, consider building in-house. And remember that not every government organization needs to be a full-scale development shop. You can:

Contract a vendor to build custom software with you.

Use open source software and collaborate with a global community of contributors and stewards.

Co-procure custom software with peer jurisdictions and share the burden (financial and operational) of ongoing maintenance.

3. Comparing options

Your TCO (Licensing) and/or (Building) analyses show the financial costs of various sourcing strategies. There are also non-financial costs and benefits associated with each. Think of the long term impact that each strategy will have on your organization.

This project is an investment in your organization’s future.

Consider the long-term value or risks that might arise with each of your options:

Ownership: How is it owned and distributed? Most national governments encourage their agencies and sub-national governments to transition software they build or contract to an open source licensing model—which provides general benefit to the public.

Cost: Will the vendor increase subscription costs, exact patch and upgrade fees, and or add service costs? Do you have development staff, and do they have time to build and maintain software? How might open source change the cost structure?

Security and Compliance: Will the vendor issue patches and updates? This is particularly important when it comes to complying with changes in policy (e.g. Personally Identifiable Information policy or Digital Accessibility policy).

Flexibility: Does the vendor “lock-in” customers?

Interoperability: Does the software fit your existing technical environment and workflows? Does it interface well with your partners or other government entities?

Actual use: Does the software have the features you need (or does it include many features you don’t need)?

Capacity: Could an investment in hiring new staff and/or training current staff for a software project have long-term benefits for the organization?

Compare options based on a broad set of variables

Specifically, consider the long-term value and outcomes associated with each strategy.

Shifting from Capital Expenses to Operating Expenses

Open source software is free, but it takes work to customize and maintain. Government organizations will need to either hire staff who have capacity to implement and maintain software, or contract technology service providers (writing open contracts for services, as opposed to fixed costs for digital products and licenses).

That means the cost structure will be different. Budgeting for open source software implies a shift from capital expenditure—buying a product (proprietary software)—to operating expenditure—buying services (development and integration work) or staffing.

4. Co-procurement

Peer jurisdictions (two cities in the same province, for example) often share a similar set of challenges. Co-procurement is an effective strategy for sharing the cost of obtaining and maintaining open source software that fills a common need, whether (building in-house or contracting a vendor to build and maintain custom software).

Co-procurement aligns with open source software

Sharing a single software license is impossible under proprietary licensing models, but—because open source software is free to use, adapt, and redistribute—governments are fully within their rights to collectively procure development or customization services from a technology service provider and share it amongst themselves.

Co-procurement increases value for everyone involved.

Each beneficiary makes a smaller upfront investment

Better software can be built with mutualized resources

Tax dollars go further

Increasing the number of interested suppliers. Vendors have the opportunity to get business from more than one jurisdiction.

Peers contribute to improvements in the shared code

Consult national-scale platforms

Consult platforms for match-making between jurisdictions that share needs. Reach out to peers and communicate within your networks. The Foundation for Public Code provides co-procurement support as well—reach out to us with any questions!

Takeaways