Scary Words I Hear in GovTech: Maintenance

I hear people in government talk about software maintenance a lot. What they usually mean¹ is they have paid for a software application to be built by a contractor and now they want to put it on a shelf and pay someone (possibly a different contractor) to dust it off every now and then. Maybe they’ll even pay someone (very possibly yet another contractor) to be on hand should that application fall off the shelf and break – but only if this happens during business hours (9-12pm and 2-5 ET, Mon-Fri).

Now, if you’re in the private tech sector, you’re probably confused. That doesn’t sound like product development, you might be thinking, and you’d be right. This isn’t product development, and unfortunately, it’s often not even what you might consider product support.

When companies in the private sector treat their products like this – as something to be built once and then “maintained” – these products eventually lose all their users. Sometimes companies put legacy products on life support because they intend to deprecate the product and ask their users to move on by a specific sunset date. For the rest of them, however, they lose users because their users find a better alternative that meets their evolving needs.

The government rarely sunsets products or processes. Let’s be real: we’re talking about an organization that still requires employees to fax HR paperwork.² Users also rarely have alternatives, except for when private industry comes along and convinces them that they should pay for basic services (e.g. filing taxes) or when nonprofits emerge to help with basic social needs (e.g. protecting against housing discrimination).

But just because users can’t really leave doesn’t mean they don’t matter. With government products, the users are the public, are the customers, are the tax payers. Government loses money and trust when it doesn’t solve real problems, respond to user needs, and demonstrate value. And spending a lot on software that sits around gathering dust and losing users or causing more frustrated users is rather expensive and doesn’t serve the public.

So, rather than think of software as something static to be maintained, let’s think of software as a product – in govtech, usually a product whose users are either the public or government users facilitating service delivery. The key product idea to keep in mind is that the technology isn’t the end goal: solving a problem is the end goal.³

When you’ve built a software application, you don’t measure its success by how often it doesn’t fall over – a.k.a. how well it is “maintained” – but by how well it solves the problem you built it to solve.⁴ This involves understanding users and their problems, setting goals, and building towards those goals. It involves constantly monitoring and assessing the product and its performance towards those user-centric goals. That involves continuing to stay in touch with and understanding users.

Example: Applying for a driver’s license

The problems related to this process vary from state to state, and I’m not going to pretend to be an expert. But I have been in many a DMV (Dept. of Motor Vehicles) and applied for a driver’s license in 3 states, and, as a user myself, I’ve experienced some problems. One big one I’ve faced across all three states is that it takes quite a long time to apply for and receive a driver’s license. Most recently it required multiple trips to the DMV, and at the last one, I filled out a form in person and then watched the person behind the desk type it up for me before having me double check that it was correct.

If you were the product manager for the DMV,⁵ you’ve got multiple users to think about (driver’s license applicants, DMV staff, DMV executives, etc), but in this case let’s just focus on the public user, the driver’s license applicant.

For this problem, you’ve also got multiple metrics you can look at, but for simplicity, you could identify one key metric and set an objective for it: the time it takes an applicant to get a drivers license from start of application to receiving the license. You want to decrease this time.

You’ve identified the users, problem, and measurable objective, so now you follow human-centered design principles and determine that most of the time is taken during compiling the right documents, filling out forms, and visiting the DMV. So you build an online application product that allows for complete online submission of the paperwork so users can make a trip to the DMV for just their signature and photo. Lo, after user testing and deploying the product, you find that you hit your objective. You conclude that your product successfully addresses the problem for driver’s license applicants applicants.

But you can’t stop there. And you can’t just think of future work on this product as maintenance in the form of bug fixes, security, and system uptime.

Users change. They change in demographic makeup and how they use technology. Half of users may use this product on mobile today but next year? Maybe that’s up to 75%. If users change, their problems probably change too. In this case, hell, with the promise of autonomous cars, users are probably going to change how they use cars in the not too distant future – and what will that mean for driver’s license applications and this product you’ve built?

Technology changes. What worked on Internet Explorer 6 may not work on the latest version of Firefox. What worked on desktop may not work on mobile. What is the most efficient and secure programming language or framework today won’t be in 2-5 years, much less 10 or 20 years from now.

Policy changes. Requirements might be added or removed from the application process. Policy might even come down that mandates how quickly the DMV must process applications, which might affect how you think of product success.

Maintaining software isn’t good enough. From the time of design, development, and launch, the software you’ve built is a living part of how you deliver services, and should be constantly evaluated and evolved alongside the evaluation and evolution of your agency’s service delivery as a whole – which should include assessing customer satisfaction, impact, efficiency, and other metrics and goals.

You might even find that your technology solution no longer helps your agency’s overall goals or solves your customers’ problems – in which case, don’t be afraid to sunset the product, document your learnings, and iterate on a new solution.⁶