Process code for software procurement

Contents

  1. Goals
  2. Actions
    1. Using a DevOps approach
    2. Creating a documentation, training and maintenance plan
  3. Common challenges
    1. Staff turnover
    2. Lack of familiarity with and/or lack of involvement in the agile development process
    3. Lack of communication with end users
    4. Lack of decision-making power granted to technical experts
    5. Lack of attention and resources for lifetime ownership
  4. Checklist
  5. References
  1. Introduction
  2. Orientation
  3. Planning
  4. Assessment
  5. Implementation
← Agile development and integration

11. Integration

Diagram showing who should read step 11

Read this regardless of your procurement approach.

Goals

  • To support the vendor’s agile development process.
  • To incrementally deploy working software modules (use the “Development and Operations” or “DevOps” model).
  • To work with the vendor to produce thorough technical and user documentation.
  • To create clear plans for staff training and software maintenance.

Actions

Using a DevOps approach

Your vendor should be using an agile development approach, which means continuously producing and delivering software modules. “Development and operations” involves continuously integrating and deploying software modules in the actual working environment (technical and operational), as they are built. That means launching a piece of software on the city’s servers and/or or having users start using it in their daily workflow. This reduces the risk of incompatibility at the end of a long process and the burdensome troubleshooting that comes with it. It also means that key associated staff become familiar with the product along the way, and can even provide feedback that helps guide iterations or future modules.

  • At the end of every sprint milestone, ensure that the vendor delivers the module.
  • Work with the vendor to deploy the module in the city’s technical environment.
  • Coordinate with end-users to test and integrate the module in their daily workflow. They are the best resources for evaluation. If it isn’t functional, then it isn’t good enough – you can do another sprint. Provide feedback to the vendor.

Creating a documentation, training and maintenance plan

Using a DevOps approach means that modules will be continuously deployed into the city’s working environment. End users will have first-hand experience with the new software, and can give feedback as the product is being built. However, it is still important to document the software thoroughly. This includes technical documentation (overall architecture, modular integration, specific module function, ongoing maintenance considerations) as well as user documentation (what end users should be aware of, how to train new users, and best practices for getting the most out of the software). Hand in hand with the documentation, it is important to create a simple plan for ongoing staff training and software maintenance. These can be time- and budget-intensive, so be sure to allocate resources appropriately. Both should be continuously updated as working drafts throughout the software development process, and completed when all features are built and perform at a satisfactory level.

  • Ensure that the technical team and the product owner collaborate on writing thorough documentation (technical and user documentation).
  • Create a maintenance plan that includes:
    • Regular (annual) performance audits.
    • Staff training plan to onboard new users in the future.
    • Staff time for software maintenance and updating (particularly if the city’s digital infrastructure changes in ways that affect the software performance).
    • Strategies for sharing with other jurisdictions (if it is custom software or OSS).

Common challenges

Staff turnover

Retention and continuity can be a significant challenge, particularly for technical expertise – where city governments have to compete with private sector software companies for talent. Staff turnover can confuse a process and cause delays.

Lack of familiarity with and/or lack of involvement in the agile development process

City staff assume that they cannot or should not be involved with the developer team. Coders should have decision-making power when it comes to technical architecture, timelines, and required effort, but they do not know what end users need.

Lack of communication with end users

Frontline staff members will be affected by continuous integration. It is important to notify them of changes to their daily workflow, and to seek their feedback throughout the development process.

Lack of decision-making power granted to technical experts

This can result in over-specifying or under-specifying feature sets. It can also cause misalignment on sprint plans, timelines, effort required, and budget.

Lack of attention and resources for lifetime ownership

A contract is not the end of a procurement process, nor is final product delivery. It is important to have a detailed plan for ongoing use and ownership.

Checklist

  • Working relationship with a vendor to collaboratively carry out an agile development, including modular budgeting and DevOps plan
  • Documentation
  • Lifetime use plan and resourcing

References

Agile development

https://agile.18f.gov

Project management (with evaluation metrics)

https://www.atlassian.com/agile/project-management/metrics

Budgeting and overseeing tech projects

https://derisking-guide.18f.gov/state-field-guide/budgeting-tech/

IT Product Management Integrated planning guide

https://sara-sabr.github.io/ITStrategy/2021/10/15/product-management-part-2.html

CDS Product Evaluation Guide

https://digital.canada.ca/tools-and-resources/evaluation-framework/

Open North: Open and ethical procurement guide on engaging with the private sector

https://opennorth.ca/publications/2hvkzrlujufylsvxgf7li5_en

18F: Work with the vendor

https://product-guide.18f.gov/partners/vendor/

Agile Development 101

https://www.agilealliance.org/agile101/