Replacing legacy systems in government: Lessons learned through MOVE

Jesse Coleman and Aakash Harpalani from Toronto Transportation Services share learnings and advice for others embarking on digital modernization projects in government. Hear why they decided to build new tools in-house instead of relying on vendors. Learn how they adopted more agile rituals on their team. And discover how a team from Code for Canada helped them stay laser-focused on user needs.

A few years ago, we were facing a challenge common to many large and mature organizations. We had two legacy systems, CRASH and FLOW, that had outlived their useful shelf lives and urgently needed replacing.

But our team at Transportation Services relied heavily on these aging systems; they routinely analyzed traffic volume data (FLOW) and collision data (CRASH) to understand Toronto’s transportation needs and identify potential safety interventions.

While these legacy systems were still operational, they were highly susceptible to data quality issues. CRASH and FLOW are two separate applications - but many investigations required both volume and collision data. The existing systems weren’t able to provide a holistic view of what was happening on the road. They also relied on technologies and operated on systems or software -- like Internet Explorer -- that were no longer supported internally or externally.

So we started doing what most government departments do when they need to replace software: write up a long and extensive list of requirements (including the things we might need but weren't sure about... better safe than sorry, right?) with the intent of putting out a Request for Proposals (RFP). This would lead to us hiring a vendor, who would then take our extensive list of requirements and after a couple of years (fingers crossed) would deliver a beautiful and shiny new tool that would seamlessly integrate into our existing processes.

Around this time, a couple of things happened.

First, a couple of us enrolled in an Agile project management course offered through the City's Enterprise Learning Initiative (ELI), and started integrating practices such as daily standups into our everyday work.

Second, we became increasingly tapped into the digital government movement, led by organizations such as the Canadian Digital Service, the Ontario Digital Service, and Code for Canada. They championed a modern approach to building digital products, prioritizing user-centred design and agile development by building new software within government organizations. They also shared a belief that governments can — and should — build digital services in-house, rather than relying so heavily on vendors. We had always known that traditional procurement vehicles aren’t well suited to software development. We became convinced there was a better way. 

Fast forward a couple of years to this past December to when we launched MOVE , a new and modern digital platform for the City's traffic collision and volume data. As we shared here, we ended up partnering with Code for Canada and bringing in a team of three digital professionals to help us rebuild this entire system and related processes from the ground up.

There were a number of reasons we decided this was the right approach for us.

Risk mitigation

Government's traditional, "risk-averse" approach to software procurement often achieves the opposite. 18F makes this case explicitly clear in their excellent guide. Given the lead times associated with procurements for major projects and the overall scarcity in budgets and resources, software is typically linked with multi-decade lifecycles. If you get it wrong the first time, it's a mistake that you're stuck with, with minimal room for recourse. Over time, processes evolved to fit around the limitations of that software rather than the other way around.

We knew that our existing systems were built based on programs that were designed over 30 years ago. Anchoring any future software to that outdated vision would set us up for failure. We needed the ability to really dive in with our users to understand their underlying needs. Seeking to uncover what was possible, we committed to iterating with users as they moved further away from those legacy systems.

Moreover, with rapidly evolving programs such as Vision Zero driving this development, it was imperative that we had the flexibility to adapt MOVE in the future as our needs changed.

Building digital capacity

First, an acknowledgement: Three years ago, we had no clue what it took to build a modern digital product and what skills we should be looking for. Worse yet, we didn't really know where to start. Through the fellowship process and beyond, we've relied heavily on Code for Canada and their recruitment process to figure out what roles we needed to hire for and to get talented people on board.

Not only have we now built a thing, our team has internalized many of the practices that were novel to us at the start of the fellowship. We're now at a point where we've developed enough internal capacity to start making the case for specific roles to carry MOVE forward, and a blueprint from which to build other digital products. It has provided us with the knowledge and confidence to be strategic in what we choose to build internally and what we choose to put out to the market.

Better and fairer procurements

As an organization managing a large, complex, and integrated transportation system, one of the major challenges we face is that once we start integrating a piece of technology, we quickly become reliant on it. As a result, our procurements often evolve to require a very specific list of requirements. What used to be a wide range of potential vendors gets narrowed to only one or two organizations that can truly compete for those contracts.

Transitioning to a process under which we, as City staff, own the product development cycle means we greatly minimize the risk of vendor lock-in. This allows us to make architectural decisions and ensure that this development is conducted in a language of our choosing using coding practices and common data standards that we've adopted internally.

We get to build something that is aligned with the skillset of our staff (and therefore have internal capacity to support), and we can also easily tap into an incredibly rich ecosystem of digital product talent right here in Toronto (and beyond) to maintain and improve it.

Lessons learned

All in all, we've grown immensely since those early discussions around replacing CRASH and FLOW. While we still have a long way to go, there are a few things that have become increasingly clear in our journey to this point.

1. You need champions across the organization at all levels (not just senior management)

It's a given that you'll need to get the decision-makers that are accountable for how City resources are spent on board with your vision. The success of MOVE, however, was driven by the buy-in of staff using the product for their day-to-day work. When we launched, we had people across different teams who had already tested and used beta versions of MOVE for months. They were invested in its success. We could also rely on these champions to extend our educational reach beyond the standard offering of training videos and sessions.

2. Embedding digital professionals is a great way to fast track your own team's growth

Coming from a pretty traditional engineering-driven industry, the standard contractor model is to hand off work to consultants, check in periodically, and then receive the agreed-upon deliverables at the end of the project. The alternative model we've used here of embedding digital professionals within our team has been so incredibly valuable, and has really leveled up the practices within our own unit. Aside from the development of MOVE itself, our Data and Analytics team has gained so much through osmosis by working alongside people with different skill sets.

Some of these are tangible things that we've adopted in our team: retrospectives, code review processes, having developers and designers around to bounce ideas off of, the constant focus on the user, and better technical documentation.

3. Planning for product sustainment is hard

We would like this application to live on and evolve to be at the centre of safety and mobility decisions across the City for a generation to come. This is fundamentally hard, in particular coming from a place of little knowledge and IT systems and digital product development.

We don't have it all figured out, but some of the pillars we are leaning on include relying on widely-used open source technology, building a free and open source product, adopting a modular and scalable approach, and working collaboratively with our colleagues in Technology Services.

One final lesson for sustainment, is that success is not just sustaining the product, but also internalizing the lessons we've learned through the process, most importantly from building with and constantly listening to our users.

4. Everything starts and ends with great people

We've been so lucky to have had a progression of incredible product team members, starting with the Code for Canada fellowship. These committed professionals have devoted themselves to the project, seen and understood the opportunity that it presented in terms of making a meaningful impact on road safety goals for the City.

This industry can get easily distracted by the newest shiny technology, but ultimately the technology is secondary; get great people, set up conditions for success and let them deliver. Shout out to everyone who has got us this far: Evan, Shine, Maddy, Ruth, Andrew and Pal.
 

You're here to help residents, and we're here to help you. Interested in how to bring digital tools and skills into your department? No matter where you are on your digital government journey, learn more about how Code for Canada can support your work.