Guide to Buying Local Government Websites

Posted on February 21, 2020


Guide to Buying Local Government Websites

Contributed by ELGL member Kevin Herman, chief operating officer of ProudCity. This post is part of a series on best practices for buying, launching and maintaining great local government websites.


The Guide to Buying Local Government Websites empowers government leaders to make holistic, intelligent decisions when it comes to procuring quality online services needed to best serve increasingly digitally-centered communities.

Local government leaders must be experts in all aspects of public sector management and, as technology evolves at a rapid pace, you are increasingly challenged with understanding new business and technical issues that are critical to sustainably and successfully serving your communities.

The Guide to Buying Local Government Websites provides an accessible foundation for all stakeholders — city managers, mayors, council members, technologists, communicators, directors, and other staff — to align on principles, purpose, and approach so that the best decisions can be made that serve the needs of everyone.

Use this guide to unify your team and start your digital modernization efforts with the confidence of an expert.

You’ll make a smarter decision, have a much better final product, and your communities will thank you.

Checklist

  • Appoint a leader
  • Establish purpose, guiding values
  • Familiarize yourself with Digital Government Standards
  • Publish request for information (RFI)
  • Schedule product demos / Q&As
  • Test-drive options
  • Announce final selection

Dos and don’ts

Do

  • 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’t

  • 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 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 (decades even) 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.

Playbook

Here are the key plays to execute your government website search and procurement process with confidence.

Appoint a leader

As with any successful project, there must be one person that is given sufficient authority and support and ultimately held responsible for its implementation. This person, typically known as a product owner, assesses organizational business needs, establishes vision, thoroughly researches the options based on the given budget and leads from procurement to launch.

As 18F notes of the product owner:

“They’ll be responsible for establishing and carrying the long-term vision of the project, implementing a strategy, and guiding its progress, as informed by user research. … The product owner removes obstacles and helps the team work as quickly as they can. They make decisions independently and have sufficient authority to make changes large and small to the product without additional review from superiors.”

And, as the U.S. Digital Service notes:

“All stakeholders agree that the product owner has the authority to assign tasks and make decisions about features and technical implementation details.”

Empowering one person as product owner, led by guiding purpose and values, eliminates confusion as to who is responsible for making decisions with the entire organization in mind, and who will be held accountable for the success (or failure) of the project.

Establish purpose

Rather than focus on compiling a vendor list or itemizing technology preferences, you must first establish purpose and guiding principles to reference when/if the team needs grounding or reminding of the holistic end objectives.

For purpose, this includes focus on meeting mission-critical community needs:

  • Service delivery: How people access your services online.
  • Community engagement: Meeting your community wherever and whenever, interacting when it’s most convenient for them.

Create guiding values

To complement purpose, establish values for how you will approach your relationship with vendors partners. These will be a point of reference for strategic, tactical and technical decisions.

For example, San Rafael, Calif., approaches its vendor partnerships with these values:

  • Authentic and responsive engagement
  • Transparency
  • Accessibility (user-centered design, mobile-friendly, ADA compliant)
  • Continuous improvement and learning

Get buy-in

The key component to any successful digital project is buy-in, so that the initiative can get financial and moral support. Be sure to include and get alignment with all internal stakeholders:

  • Leadership (city managers)
  • Elected officials (mayors, council members)
  • Communications, media, public relations
  • Departments/agencies
  • IT

Clarify roles/responsibilities

Each member of the government team and hierarchy has specific roles and responsibilities. It’s important to clarify these upfront so that everyone within the organization understands how they can effectively contribute to a successful digital project launch.

Product owner

  • Navigates procurement process
  • Makes final product decisions
  • Serves as vendor primary point of contact
  • Assembles project team
  • Assigns tasks to team
  • Keeps stakeholders informed on progress/decisions

Leadership

  • (city managers)
  • Selects product owner
  • Empowers/supports product owner
  • Provides resource support (financial/personnel) to the project

Elected officials

  • (mayors, council members)
  • Provide resource support (financial) to the project
  • Provide input on project goals/objectives and success metrics
  • Empower/support product owner

Communications, media, public relations

  • Content development/strategy
  • Branding / positioning

Departments/agencies

  • Content
  • Service delivery insight
  • Integration insight

IT

  • Establishes governance
  • Executes technical needs (DNS, etc.)

Understand emerging technology trends

Familiarizing yourself and key team members with the modern technology landscape will empower you to make intelligent, sustainable, scalable decisions that best serve your communities.

Key terms/concepts:

  • Platform
  • Software-as-a-service
  • Application programming interface

Familiarize yourself with Digital Government Platform Standards

Digital Government Platform Standards provide baseline compliance guidance for meeting continuous technology, security, mobility, accessibility and data portability requirements, as well as ultimate procurement flexibility.

Standards are often mistaken with features. They are closely related but there is an important distinction between the two: Digital Government Platform Standards defines how the features will operate. For example, websites must be mobile responsive as a standard which then dictates that all features are also all mobile responsive. Therefore, your events, payments, web forms features are all mobile responsive by default to the standard.

Digital Government Platform Standards

  • Free trial: Yes
  • Continuous feedback loop: Yes
  • Ubiquitous platform updates: Yes
  • Recurring release schedule: Yes
  • Encryption: 100% HTTPS
  • Accessibility: Level AA
  • Mobility: Adaptive/responsive
  • API: Yes
  • Subscription-based pricing: Yes

Publish a request for information

A request for information helps change the framework of the purchase to focus on the intent of the services provided, rather than the purchasing process itself. Governments should provide needs, goals, standards, timeline and, if available, budget that act as a guideline for vendors to deliver detailed information on how they would deliver their services within those broad parameters. It is then up to the vendor to provide a clear and informative path to achieve government’s goals in time and on budget.

RFIs:

  • Increase your understanding of available options
  • Avoid predetermined processes
  • List suggested features, rather than heavily-specified requirements
  • Separate standards from features

Get a demo

A product demonstration gives you an opportunity to ask questions and have the presenter provide tailored information to your needs and understanding. By being an active part of the conversation with questions and personal insights, you learn more about the vendor than what’s presented in polished marketing material.

Test-drive your options

The only way to fully understand whether a government website service  provider meets your mission-critical needs is to actually use that product. Most software-as-a-service companies provide free trials for a limited time, so make sure you take advantage of this benefit.

If a vendor is unable to offer a free trial, their process most likely entails a custom, bespoke approach. While this is certainly an option, many local governments with finite resources should opt for software-as-a-service, as there are long-term benefits related to ongoing product enhancements, bug fixes and security updates.

Feel great about your decision

Modern technology, particularly software-as-a-service, has created an incredible opportunity for governments to cost-effectively better serve their communities in ways previously available only to larger organizations with infinite resources.

New, innovative companies are emerging that now offer fresh, invigorated approaches to government technology. This new energy will show up in the product design and customer support for the duration of your relationship with your selected provider.

So, when making your final decision, you should feel extremely confident you made the right decision, with the right partner, who will continuously inspire you to proudly serve your community.

Questions for vendors

In the event these items are not addressed in the RFI/RFP response, get clarity on the following:

  • Do you meet the Digital Government Platform Standards?
  • How often do you release product updates?
  • Do all of your customers receive these same updates (approx. at the same time)?
  • Are there additional costs for these updates?
  • What is included with your support offering (service level agreement)?
  • What is your software license?
  • Do you have an open API? Can you provide a link to this information?
Close window