1. Orientation
4a. Implementation phase
The fourth and final phase is about implementation. If you are working with a vendor to build custom software or adapt open source software, you will go through an iterative cadence of planning, building, deploying and testing in short, 2-4 week “sprints.” Your role is to scope each sprint together with the development team, create a budget and a micro-contract, facilitate deployment into the city’s technical and operational environment, evaluate that deployed product, and provide clear feedback to the development team.
That sounds like a lot of work—and it is—but remember that you’re in control at each step along the way. You determine the scope, you can decide whether or not the module is working well, and whether or not to continue with the vendor. Too often, people assume that once the contract is signed, they can sit back while the vendor gets to work. However, the best software is made when the client team is actively engaged in the agile development process.
You will continue running through sprints and creating individual modules until the full feature set is built and deployed into the city’s technical environment. At that point, you’ll 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 technical 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, and onboarding protocols. Staff turnover is always a challenge, 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 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. That means your peers will find it useful, and they will have a lot to contribute as you maintain the software over time. The final step in this process code is focused on creating or joining a community of practice.