Technology Isn’t Magic — And 4 Other Lessons Government Agencies Need to Know Before Buying Software
By: Alex Lawrence
Tags: Procurement Software, Digital Services, Bloom Works, Civictech, Government Services

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.