Do’s and don’ts when buying local government websites

Dos

• Appoint one person, the product owner, to lead the process and empower them to make the final decision, especially if they are the primary users/administrators.
• Establish business rules/needs and guiding purpose/principles first (not vendor lists or technical specifications).
• Move the process along so that you successfully launch in a timely manner and realize the immediate benefits of modern solutions to better serve your community.
• Issue a request for information to gather external input as to what your best options are with respect to your business rules and needs.
• Issue a request for proposal, if necessary, soliciting pricing information based on the RFI response.
• Schedule a product demo meeting and allow ample time for questions and answers. Use this opportunity to fully understand the specific product offering and develop a rapport with potential vendors. Include key stakeholders in this meeting. Be prepared with questions specific to the vendor. Keep it conversational. If a proposal has already been submitted, make sure all participants have thoroughly reviewed this. See ‘Questions for vendors’ below.
• Try before you buy. If the vendor is unable to provide a free trial, even for a limited time period, this might be an indication that this is a bespoke service, which may not meet long-term needs relating to product updates (new features, security updates, bug fixes).
• Pick based on continuous software updates based on a standard pricing (preferably monthly/annually subscription) and service level agreement (hosting and support).
• Request specific license information. For example, with open source, saying "we're open source" or "we use open source" is much different than "our license is "GNU General Public License, version 2 or later."
• Ensure there is an application programming interface (API) that can integrate easily with other software.
• Communicate effectively with all parties -- internal and external -- throughout the process.

Don’ts

• Buy before trying. A demo is helpful, but actually being able to test-drive the product is where you will fully understand all of its features and general user experience.
• Over-specify. Many times RFPs/RFQs are based on antiquated, irrelevant or misguided technical specifications. The business needs and RFI process will determine industry standards and not constrain or prohibit an innovative, modern service provider.
• Let the project get delayed.
• Use a grading system where everyone gets to rank and average. This places an emphasis on individual preferences, which can be uneducated or ambivalent, and significantly diminishes the importance of the business needs. It also doesn't empower or hold anyone truly accountable.
• Don’t treat product demos lightly or confine yourself to an unrealistic timebox. This is an opportunity to learn as much as possible about the product in a conversational setting and get the team aligned on the respective offerings. Don’t include participants who will not be present to the conversation or have no serious interest or ownership over the project.
• Solely base your decision on what other governments are doing. Chances are, they made their decision years ago, and the technology they are using is no longer relevant in today’s digital environment.
• Base your decision on vendor-provided references. Most vendors, obviously, will provide only references that will speak positively of them.
• Base your decision on team resumes. Software development is more complicated than what is listed on a CV, and often involves different roles and commitments at varying times.
• Don’t relegate unilateral decision-making to IT or uninvolved senior staff. Government digital efforts are not IT projects. Whether it’s a new website or any other public-facing digital service, these initiatives represent how your community will perceive government effectiveness and service delivery, and a product owner is the person who should be responsible for making the final decisions.