While requests for proposals are a staple of the purchasing process for municipalities, they can be inefficient when procuring soft ware, often deterring soft ware vendors from participating in the bidding process.(Shutterstock.com)

The number of cities investing in cloud-based soft ware is increasing, and it’s not surprising given the ability to access the soft ware and its saved data from anywhere and with any internet-enabled device. Beyond ease of use and access, going to the cloud also provides cities with the opportunity to show their constituents they are being proactive where the environment and taxpayer money are concerned by reducing the reams of paper and ink consumed.

Onvia’s “10 Hotspots in Government Contracting for 2017” shared IT bids and requests for proposals had grown approximately 17 percent from 2015 to 2016. Th ese bids included both custom and transformative IT services like cyber, cloud, big data and data center/information architecture consulting.

The report also noted when it came to IT purchasing “that many of the highest growing IT segments are in areas such as these where buyers typically lack the experience and knowledge to be highly specific about the bid language and look to providers for input.”

This lack of experience can hamstring cities and towns when it comes to procuring software, both when securing the best “deal” and the right software for specific operations.

Tammy Rimes, MPA a procurement consultant and former purchasing agent for the city of San Diego, stated procurement processes aren’t necessarily as nimble and progressive as needed for IT purchases. A bid or RFP process generally outlines the specifications and scope of work for an intended purchase; however, in the IT world, procurement doesn’t always know what they don’t know. With limited resources and training, this is an area even the most progressive procurement professional would like to have more research time and knowledge.

Rimes suggested the solution for software procurement could be multi-fold: 1) issuing requests for information that are more “open” for the suppliers to propose the latest technology; 2) allowing procurement professionals to attend IT and leading edge conferences to learn more about this field, and 3) agency IT and procurement teams working more closely together on purchases rather than within “silo” processes where the two groups rarely combine efforts. In the end, the goal for both groups — IT and procurement — should be the same: to benefit the public good.

For software vendors, RFPs can be a leading frustration as Bob Casey, vice president of operations at Aladtec, noted, “The one thing I’ve found is that the RFP process for software is not the most efficient.”

He shared he has seen RFPs up to 100 pages in length and contain anywhere from four to 700 questions. Cities have even copied terminology from a particular software firm’s website, which further discourages other companies from participating in the RFP process as the city seems to have already made its decision. A municipality can also disadvantage itself in a RFP.

“We’ve come across a section in the RFP that stated, ‘The maximum budgeted amount for this project is $120,000 (a year),’” Casey said. “This will attract the bottom-feeders who will check yes to (all the requirements) without sharing their price. ‘Oh, coincidentally, we were going to charge that much!’”

While cities might think of using the RFP process to get a feel for pricing, most reputable software vendors already have that information shared on their websites for anyone to see. However, cities shouldn’t focus too much on prices both high and low as Casey noted, “Getting the best price and best deal are not necessarily the same thing.”

The bottom line comes down to usability and whether the software is the best fit — or can be customized — for the operations it is being purchased to do. Scalability can also be an important factor, especially if some features are not needed. These bottom line items can be lost or not come across in an RFP.

“What I would do is insist on a customizable demo using their data and people to get hands-on experience,” Casey said, adding, “Things don’t always come through (when using) a check list. A good software company would provide that for free.”

Casey stressed the need to make sure the demo is fully detailed and customized. “A generic demo will show you what they want you to see, not what you need to see. A customized demo gives you a feel for what to expect on day one, day 101 and day 301.” This enables employees who will be using the software day in and day out to determine its usability and intuitiveness.

“Typically there will need to be a presentation beforehand,” Casey said. “Software can be presented remotely and is very easily demonstrated.”

A demo can also give a city a taste of an intangible component of purchasing software: the level of customer service the software vendor provides. Employees shouldn’t feel intimidated or embarrassed to call the customer service line if something happens or they require guidance on certain aspects or features of the software.

This full introduction to the software and the software vendor can ensure municipalities aren’t handcuffed in a contract with a software that just doesn’t satisfy needs.

Rimes noted the typical government contract may last for three to five years and doesn’t reflect the rapidly changing IT technology environment. She said, “Another possible solution may be to seek another agency’s established contract or a cooperative contract that has already been solicited and ready to use. By leveraging the spend across multiple agencies and using already-conducted research, this can be an effective way for municipalities to gain the commodities and services needed in the rapidly evolving IT industry. The National Cooperative Procurement Partners Association is an excellent resource for educational materials on the concept of cooperative contracting.”

Ultimately, Rimes said, “Government offices have to respect their duty to the public and spending of tax dollars. They can’t necessarily take on a great deal of risk, and must choose proven technologies or standardize on certain products for maintenance and security reasons. It would be great if they were given the latitude to research and ‘try’ new ideas, but risk is not always rewarded in a government environment, particularly if things go wrong.”