Why Are Cities Still Signing Long-term Technology Contracts?
Published: March 23, 2018
Can cities pull themselves out of a purchasing cycle that only benefits vendors?
A recent article raises a number of interesting questions regarding local governments and the methods by which they tend to procure various technology requirements, in particular software. Drafting RFPs for software can be challenging, considering the range of possible software needs the City might have. Historically, contracts for software were adopted because that’s how other services have been acquired in the past. They remained the norm during the era of on-premise solutions that required cities to have ownership of software solutions, and are still lasting today in the age of cloud-based applications. In light of this situation, there are some frustrations that have arisen: 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.
The article contends that these long-term contracts are set up in a way that can hinder the work of local government officials. These contracts can set vendor incentives against building and enhancing software over time. Instead, one possible fix could be the use of short-term contracts, perhaps even month-to-month, in which vendors must continually improve their products. Additionally, in a contracts-based process, software buyers are not usually the people who will end up using the product being acquired, which can result in RFPs being developed that do not consider or fully incorporate the end-user needs and desires.
According to the author, changing to a shorter-term purchasing model may yield several tangible benefits: It makes end users happier; could shorten and simplify the RFP building process; and, importantly, could drive more choices of software for governments. To conclude, the article asserts that moving in this direction would be good for government, good for software providers, and good for the constituents who ultimately benefit from better tools used by government. At this point, however, many government entities remain on the contract-based model of software purchasing. The article acknowledges that the use of contracts continues today but raises interesting points on that could possibly lead to future contracting changes that would be worth monitoring in the future.