When a government employee creates a software RFP, trying to enumerate every possible requirement the city has for the particular purchase can feel like climbing a tall mountain. And long contract lengths can seem laughable — when was the last time in your personal life you got locked into a 60-month contract for software?
The history of government software contracts is long, but it can be summed up quickly. First, contracts were adopted because that’s how other services were purchased at the time. Then they stuck around during the era of on-premise solutions that required cities to have physical ownership of software solutions. Now they’re lasting (somewhat successfully) due to procurement processes in the age of cloud-based applications. The result today is that many cities are frustrated and stuck in an ugly purchasing cycle that only benefits vendors.
This frustration is completely understandable, because contracts for cloud-based software are problematic for a few reasons: They create misaligned performance incentives between vendors and cities; they require buy-in from many stakeholders who may be only peripherally aware of the needs of end users; and they generate large amounts of work in the form of exhausting RFPs. Finally, contracts feel antiquated in a time when other software can be tried risk-free because billing happens on a monthly basis and users can cancel at any time.
Local government offices are composed of some of the most organized, focused professionals out there, delivering amazing services for their communities. They deserve software tools that help — not hinder — their important work. Unfortunately, long-term contracts set vendor incentives against building and enhancing software over time, as they set their sights on new customers rather than retaining existing ones. When contracts are short-term (or even better, month-to-month), vendors are forced to continually improve and evolve their products, or face swift cancellation.
In other words, vendors must earn their customers’ business every single month. When governments start to realize they hold the power in the relationship by holding vendors to a higher standard, it will cause a sea change in software offerings industrywide.
Moreover, in a contracts-oriented process, software buyers (typically procurement teams in cities) aren’t usually the people who will end up using the software being purchased. They are super-experienced negotiators and managers of valuable government finances, but not the individuals using products. They end up building RFPs without translating end-user desires into the requirements that end up being critical during project rollout, frequently because end users are so deep in work that they aren’t able to partner deeply on the writing (after all, their job is to deliver great services to constituents, not design the perfect software solution for their needs).
Without contracts in place, end users can be sold to in a direct manner — they can “taste the goods” themselves, so to speak. This ensures that stakeholder interests are aligned throughout the purchase process, and makes it far more likely that everyone will be happy with the product they now have to use.
Ultimately, this doesn’t just make end users happier — it also saves procurement teams a ton of work in the RFP building process. Many RFPs have hundreds of requirements built into dozens of pages of explanation. While these requirements are detailed and extensive, lack of cooperation from end users or other teams can leave holes even in the best-laid plans. The procurement team then ends up responsible for centrally deciding on software that goes to another team — with a work-benefit analysis to their detriment.
Most importantly, dropping contracts from government software purchasing allows government offices to try software risk-free. In six of America’s biggest cities, individual offices have experimented with my own company’s software with two or three users before rolling out to a larger city deployment. They’ve had the ability to see the proof in the pudding without setting themselves up for a risky engagement with a relatively young vendor. Even better, they’ve been able to truly use it — no holding back, as users tend to do when in a free trial.
Finally, it’s critical to observe that moving from a contracts-oriented to monthly sales model will actually drive more choices of software for governments. Currently, the bar to entry for any vendor is high, given the lengthy contract time and governments’ proper aversion to trying out new vendors with a long-term commitment. Vendors who are willing to sell month-to-month, while putting their business on the line, will see more interest more quickly because of the relatively risk-free nature of engagement.
Moving away from contracts is good for government, good for software providers and good for the constituents who ultimately benefit from productive tools in government.