Process code for software procurement

Contents

  1. Read on

Contribute on GitHub

  1. Introduction
  2. Orientation
  3. Planning
  4. Assessment
  5. Implementation
← Contracting Agile development and integration →

Implementation phase

Read this regardless of your procurement approach.

The fourth and final phase is about implementation. Whether you are building software in-house or collaborating with an external vendor, this is when agile development happens.

You will go through an iterative cadence of planning, building, deploying and testing software – what are often called “sprints.” Each sprint lasts 2-4 weeks, and it is focused on a single module that addresses a particular user journey. The sprint should be scoped, budgeted, and contracted collaboratively between software engineers, product owners, and any associated legal staff. At the end of the sprint, the module will be fully developed and operational(often called a DevOps approach). That means end users can start testing it and giving feedback, and it means you’re in control of the next steps. You can decide whether or not the initial software idea was the right one, whether or not the module meets your expectations, and whether or not to continue with the vendor.

You will continue running through sprints and creating individual modules until the full feature set is built, deployed to the satisfaction of end users, and fully integrated with the city’s technical environment. Return to the initial user journeys and problem statement you wrote. How does the end product measure up? Did you solve the problem or seize the opportunity? Does it exceed your expectations?

Throughout this process, you also have the crucial responsibility of ensuring that the software is set up for longevity. If you are working with a vendor, make sure that the city’s technical staff collaborate on writing thorough documentation. The more you can maintain, troubleshoot and update the software in-house, the better. It is equally important to document from the end user perspective – noting best practices and how the tool fits within the job description and daily operations of municipal service delivery. A common risk is staff turnover, and clear documentation is key to making sure that know-how and expertise doesn’t disappear with individuals.

Your plan should also include regular performance audits, staff training and onboarding protocols, resource allocation for software maintenance, and – if the software is open source – a plan for sharing with other jurisdictions. If you have followed this process code well, there is no reason that you wouldn’t have an excellent product that fills a real need in the public sector. You should be proud of it, and others should find it not only useful, but also inspiring!

Read on

If you are building software in-house, hired a vendor to build custom software or hired a vendor to customize existing open source software, read step 10: Agile Development & Deployment and then step 11: Integration.

Diagram showing who should read step 10

Skip ahead to step 11: Integration if you bought off the shelf software.