Technology Isn’t Magic — And 4 Other Lessons Government Agencies Need to Know Before Buying Software
Is your government agency ready to buy a technology solution?
You’re getting pressure from your peer departments to buy a new technology system. You’ve secured the budget, done some research, and maybe even received a demo or 2. Your procurement team has given you a recent Request for Proposal (RFP) to start from. You steel yourself for months (years?) of implementation pains but are excited by the possibilities this new technology will bring. You’re ready to RFP! I’ve been there too. And I’m going to ask you to do the most difficult thing: PAUSE.
Over the years, I’ve learned that this “technology solution” is rarely (if ever) the panacea you’re looking for. Having worked in the City of Boston’s Department of Innovation and Technology for almost seven years, I’ve been through my share of implementations — failures and successes. And now at Bloom Works (Bloom), in my role of supporting partners in government, I thought this post could serve as a guide for some key things I wish I had known before taking on a technology implementation in government.
Failures in government technology implementation are well documented, often epitomized by the example of healthcare.gov. And for every big, largely publicized failure like that one, there are hundreds of smaller failures — systems that never went live, projects that vastly exceeded budgets and timelines, or systems that didn’t do what was needed. When these systems fail, they don’t only leave wasted time, taxpayer dollars, and technical debt in their wake — in many cases they also have real, even life-threatening consequences.
Yet despite these failures, those of us who work in government Information Technology (IT) constantly hear, “We have X problem, and we need technology to solve it.” And even more commonly, “We need [insert shiny new tech here] to solve our problem,“ without a clear definition of what the problem actually is (more on that later).
I once had a very wonderful colleague call my team “the magic technology fairies.” The sentiment was very kind, but the implications of this kind of thinking can be disastrous.
Government IT work is hard, and it’s not easy to see what we could be doing differently. Deadlines are tight, resources are constrained, political pressures abound, and the consequences of getting things wrong matter to real people!
So in the spirit of helping reduce your stress levels, here are some tips for setting your project on the right path — before you release that RFP.
1. Define — and agree on — the problem to solve.
As I said in the title, technology isn’t magic. It won’t solve all of your problems, especially when those issues are rooted in process, org structure, and culture (spoiler alert — they are).
A project is undoubtedly going to involve tradeoffs, and all internal stakeholders need to be aligned from the get-go about which priority is the most important:
- Is it to improve user experience for your constituents?
- Improve efficiency for internal employees?
- Streamline services that are too complicated?
- Collect and share data to make better decisions?
- Have a more sustainable technology infrastructure?
You may be tempted to say “All of these please!” But if you’re trying to solve a lot of problems at once — without a single, driving priority — this is probably a hint that your project is poorly scoped.
Almost any technology vendor will tell you that their technology can do everything you want. They’re probably wrong (although I would be delighted to learn about a magic bullet out there).
You need a clear and shared vision for:
- Why you’re implementing this technology
- Which pain points you expect it will (and will not) solve
- How to resolve the non-tech barriers that will continue to exist post implementation
2. Define your desired business process.
Process mapping is an essential part of implementing a system. (For more on this, see our post on process mapping.) If you don’t know what your process is, there’s absolutely no way technology can solve your problems.
Process maps can help you identify areas that aren’t clearly defined with logical next steps. A new technological system might be able to streamline your process, but only if the process you rely on is well defined with logic. This doesn’t have to involve upending your process entirely (though there are excellent resources if you’re ready to do that).
If you don’t have a defined process, technology can actually make an automated process much worse than a manual one.
I once heard someone very senior saying — “Well, there’s no way this technology system can be worse than the million spreadsheets I am using today.” That is absolutely false! A system that’s set up but not well defined can be much worse than using a million spreadsheets with humans who’ve created a system around them.
Mapping a process is very much a “stitch in time saves 9” situation. Often as you get close to reaching go-live, people will test a system and say that it’s not working properly. Sometimes this testing will uncover a genuine technology bug. But perhaps even more common, you will uncover that you actually didn’t have agreement on how it was supposed to work. If parties are disagreeing about how the thing is supposed to work at the very end, this could sink your project.
3. Build it yourself or be willing to change.
In today’s world, when people buy technology systems, they typically buy products called software-as-a-service (SaaS). You buy a software product that’s pre-packaged to do a specific set of things, and the vendor hosts that software for you (think Google Suite or Salesforce as examples). When you think about SaaS, consider these 2 types of products:
- Systems that you’re going to co-develop alongside a vendor / implementation partner and then eventually own and maintain
- Systems that you implement mostly as-is, and you change your business process to meet the design of the product.
If you don’t have alignment on which approach you’re taking (and if you don’t budget or staff accordingly) this is a big red flag!
With SaaS, you can rarely have it both ways. If a vendor tells you their product allows you to completely configure their product to meet your needs, but there’s no maintenance required to do it, you should be very skeptical!
If you aren’t willing to rethink the way you do business (or you feel like you can’t due to complex regulations, etc.) then be prepared to own and support the system. This means having actual humans who are qualified to maintain the system. These folks can be contractors or employees, but they will be most successful when they’re embedded in the organization and understand the culture and processes. This probably means investing money, and trust me when I say your budget folks will NOT be happy if you aren’t clear about this up front.
4. Break your project down into manageable chunks.
There’s one big truism in technology implementations that’s often counter-intuitive. It’s far easier to implement a brand new system than it is to replace an existing one.
Why is that? When you have an existing system, folks think you need to replace every single feature set you have today in order to go-live. This means the project is probably going to keep going and going until you have something so complicated and that has dragged on so long that no one has the energy they had when they started.
You need to break this way of thinking from the outset. You may have to go backwards just a little bit to go forwards (remember what I said in the beginning about picking priorities?). You also may have to have more than one “system” implemented at a time. It’s tempting to think you need one big system to do everything. You probably don’t.
These steps can be daunting. I understand how hard it can be to get the organizational buy-in to make a better plan. But I’ve also seen firsthand — over and over — how much more work and money it can add to NOT take these first steps. In fact, witnessing these missteps is what inspired Lauren Lockwood — the former City of Boston Chief Digital Officer and my current colleague — to start Bloom.
I learned these 4 lessons the hard way, and it’s now our mission at Bloom to guide civic organizations along an easier, less painful path to make sure their IT projects are successful. Unfortunately, we can’t pull a rabbit out of a hat. But through some important pre-work, your organization can take necessary steps to make the best out of technology.
Pollinator is an open space for sharing lessons learned and insights curated by Bloom Works. Have practical wisdom to share with other changemakers in this space? We’d love to learn more. Drop us a line at — pollinator@bloomworks.digital
