I wanted to kick off our blog series with a series of posts that went ahead and answer the first question I might ask coming to GovPossible: ‘Why?’. Why start a software company now? Why in this space? Why just for municipalities, and small ones at that? I had several false starts as I tried to answer everything in one post, and thought I’d start with the most basic question: why another software package?
I’ve been working with municipalities for almost two decades and helped about a dozen select and implement various software packages. Over that time I’ve seen some decent packages and some truly terrible ones. All of them though have largely left my customers short of completely satisfied, thinking; ‘We did all the work to get to *this* point?’.
As I look back on those experiences, the following thoughts kept surfacing:
- Small Municipalities Need Good Software: 90% of municipalities have a population under 25,000. These municipalities don’t have the resources to do the coding to integrate best-of-breed solutions, nor really need to spend tens of thousands of dollar to maintain infrastructure locally, yet that’s what most are asked to do.
- Municipal Software Should Be Easy To Use: Look, I get it, the software can do all these amazing things, so what’s one more field or button? The thing is, it shouldn’t be a nightmare to switch to a new system, nor should it take a day of training to learn how to create a purchase order.
- It should be easy to implement: I’ve worked on too many projects where from kickoff to go-live takes over six months.. for each module of the software. Yes, there are complex processes in place, and we all know getting municipalities to standardize is a Sisyphean task. But why not spend the time working intensively and closely with the municipality to setup the software to their needs?
- Date Migration is not Staff’s Job: Over the past decade as software companies have tried to eek out more margin from each project, migrating the old data has gone from something that was the responsibility of the vendor to now where the department is given a spreadsheet and it’s their responsibility to get the data into that format. Last I checked, none of the department heads I know had ‘data scientist’ on their resume.
- Software Should Improve the Situation, not just Change the Platform: I’ve spent time with several municipalities well past their implementation. Almost without exception, they’ve moved because they had to leave an old technology (a Windows NT system running an iCobol application, an iSeries that was running out of maintenance, a software package that was no longer supported). After two years, their now on a new technology platform, with a few new features, but they’re not significantly better off. This may sound a little hand-wavy, so let’s be specific: the software should offer an opinionated, best-practices way to measure and improve the function it enables. It should also encourage behaviors of transparency and efficiency for both staff and constituents.
- Software Should Enable the Future, not Just Audit the Present: Outside of a basic budgeting function that compares the requests of departments for next year with previous years, most of the software packages have little to no forecasting capabilities. As a result most municipalities are flying blind from year-to-year having to react to outside changes instead of being able to leverage the decades of data they and other municipalities have to proactively manage. Software should be able to leverage that data to help municipalities be proactive.
This is what drove us to start GovPossible: the belief that there is a better way to supply software and that there are municipalities out there that share that belief. I’d love to get your feedback and hear if there’s anything that we’ve missed!