How to Modernize Digital Services Without Throwing out the Baby With the Bath Water

How do you deliver modern and user-friendly digital content and services when anchored by years of acquired habit and vintage infrastructure? If you clicked on this post in the hopes of learning an elegant method for scrapping your much-maligned technology with something flashier, you’ve come to the wrong place! Starting “fresh” can sound pretty appealing when you are frustrated with the current state, but while it is easy to pin all your problems on scapegoat technology, replacing it won’t do you much good if it turns out that your pain actually stems from operational inefficiencies. While some circumstances call for a technology overhaul, this strategy should be considered only after thoroughly evaluating existing technology and operational processes.

Exhaust existing resources

What is the actual need? What purpose is the current software or product meant to serve? Can you prove that existing tools are not meeting the need? I’ve seen people take one look at existing technology, call it “ugly” and conclude that we ought to replace it. If we think that existing technology isn’t user-friendly, for example, let’s invest in user testing to give us actionable feedback, then see if the current product owners can make the necessary changes. It is quite likely that the existing technology is not stretched to its design or functional capacity; if leadership doesn’t care to invest in it, why should the developers?

Define business processes

Again, what is the need? What is the intended behavior of the product you seek to replace or procure? Make sure you’re not jumping to conclusions about what technology you need before being able to define its intended use; how do you know if your existing tools are inadequate if you don’t know what they are supposed to do? I mostly work on transactional processes that require workflow tools. At least in this context, technology is not the end goal – it is a means of service delivery. So, before replacing or procuring a software tool, you need to have a strong sense of existing business processes. Once you have mapped the current state, it may become clear that there is a lot of work to do around process improvement before you’re ready to codify it into a workflow software tool.

So you think you’re ready to buy?

If you think you are ready to go bid, you should consider the following:

• Do you have internal ability to validate claims from vendors about how easy it is to customize a product to meet your specifications?
• If doing a modular procurement, do you have a strong internal technical lead to mediate between vendors? What is the state of your API infrastructure?
• What is the state of your “foundational” or enterprise-wide data sets (e.g. contacts/constituents, properties/addresses)? Will this project require data cleaning, conversion or analytic services?
• Do you have the resources and strategy to drive adoption of this new technology across intended users?

If you don’t yet feel prepared to define business requirements with the clarity needed for an RFP, you can release an RFI as a way of performing market research. We pursued this approach in preparation for a new ordinance set to take effect in January regulating short-term rentals; as a result, we realized we had the in-house capacity to build a couple of the components we’d need for our implementation plan. When we finally went to bid, we felt confident that we had exhausted our existing resources and were thus pursuing the most resource-efficient implementation plan.

Often, the scariest part of “legacy” infrastructure is that it was not implemented properly, adopted fully, maintained well or some combination of all three. Starting fresh may sound better than investing in deep fixes to technology that’s already in use, but if technology wasn’t the problem to begin with, why would new technology yield different results? Additionally, it is common wisdom that retaining employees is cheaper than hiring new ones; the same can be true for non-human resources. Responsible investment requires that you evaluate the need, define requirements and exhaust existing resources. If you are championing procurement of a technology that will fix a previously failed implementation, you have to be able to explain how it failed in the first place, or history may repeat itself.

Susanna Ronalds-Hannon is part of the GovLoop Featured Contributor program, where we feature articles by government voices from all across the country (and world!). To see more Featured Contributor posts, click here.