The Ad Hoc Government Digital Services
Playbook

Digital services need:

Delivering an effective digital service is distinct from building traditional enterprise software. Enterprise software starts with an organization-centric approach based on internal data, structures, and processes. This structure can confuse users and often has little emphasis on the quality of their experience.

Effective digital services must be designed around users’ needs. Users expect digital services to be responsive, available, and usable. Organizations need to adopt a digital service approach to their team structure and technology choices to meet these expectations.

Successful digital service delivery teams tend to be cross-functional and fully vertically-integrated, from user research and design all the way through development and operations. They take a product management approach to delivery, which means being responsible for the entire user experience. They measure success in outcomes for users rather than outputs that meet requirements.

Play 1 Checklist

• My delivery team has experience with the design, development, and operations of an entire consumer-facing web and/or mobile application.
• My delivery team has experience conducting user research sessions and incorporating their findings along with data from site metrics and analytics into the product roadmap.
• My delivery team has experience deploying to production and supporting a digital service in production.
• My delivery team is responsive to change and can adapt its development and delivery processes to changing priorities and new information.
• My technology stack resembles a modern delivery stack tailored for end-user services.
• My service is intuitive and does not require extensive training to use.

Play 1 Key questions

• Do our users need to know how our organization is structured to use our product?
• If that organizational structure is important, are we relying on products that require an underlying knowledge of how government operates? Are these government-specific processes impacting the user experience?
• Is our product structured around an internal business process? Has its user interface been modeled around an existing enterprise data set (as opposed to adapting the data to fit a well-researched user experience)?

Instead of searching for problems to solve with the latest technology, identify the highest value needs of users and build towards those. Invest in initial user research before deciding on a solution to solve the problems you’ve identified.

Conducting a discovery phase of research on your problem and your users can pay significant dividends throughout your project. Starting development without this research can lead to increased costs and delayed timelines to retrofit your product to match reality.

Expand interviews beyond users to:

If you have limited time and budget, a thorough understanding of the problem and potential users allows your team to prioritize development. You can deliver results faster, avoid unnecessary work, and increase confidence in your final product.

Discovery research helps you optimize what you’re building for the greatest number of users.

Play 2 Checklist

• We conducted initial user research prior to issuing any RFIs or RFPs, or have a flexible contract that allows for this before the start of development.
• We started by researching the problem instead of starting with a technical solution and working backwards.
• We continue to conduct user research at regular intervals to make sure we’re building the right thing.
• Our contracts are structured to permit discovery and exploration research cycles.
• Our solicitations are looking for details on methods and processes, not solutions, because our solution will evolve as we build and learn.

Play 2 Key questions

• Are we providing the time and space for proper discovery without rushing to development?
• Are we shelving user needs because they aren’t easy to implement with our current solution?
• Are we assuming or dictating a technical solution?
• Are we dictating the use of a specific technology without a basis for why it can serve users better?

Technologists should be a problem-solving partner for policy and subject matter expert staff. Be they engineers, designers, researchers, or product managers, your delivery team can add value to your product beyond design and development.

Software engineering is the encoding of business requirements and rules into software. Policy and subject matter experts should sit down and collaborate with technologists, not just in the initial conception and ideation phase, but in all phases of the process.

Good engineers can suggest:

Subject matter experts are even served well by sitting in on software demos, user research sessions, and incident responses so they can see how their software carries out their goals in the real world.

Play 3 Checklist

• We’ve discussed business rules with the delivery team as partners in discovering a path to implementation.
• We make subject matter experts available to the delivery team at all stages of the service’s lifecycle.
• We’ve outlined our business metrics and identified success criteria.
• We have a process for incorporating feedback from designers and engineers as they encode our business rules into software.

Play 3 Key questions

• How often do subject matter experts attend sprint reviews or listen in on usability test sessions to see the product in action?
• How do our subject matter experts communicate business rules to our technical team? Do both parties have a common framework and definitions?
• How do we balance business rules with usability?

Making space for flexible, agile teams requires a change in how agencies traditionally structure software procurements.

Combine build and operate
Digital services need to be built and operated by cross-functional teams. Instead, contracts often separate development and operations teams. This is a recipe for unstable and poorly managed services.

6 + 6 + 6…
Structure your contracts as a six month base period with several six month option periods. This allows for discovery and prototyping in the base period and time to make a more informed decision to either execute an option or pivot.

Cultivate long-term relationships
It takes time for companies to build strong teams that understand an agency’s requirements and users. Identify the outcomes that meet user needs, then cultivate relationships with vendors that have a track record in enabling those outcomes.

Keep your SOWs up to date
Frequently update your statement of work with the newest information from your project to ensure you’re prepared to re-compete the contract if necessary.

Play 4 Checklist

• My team understands what agile software development practices look like.
• My leadership understands we will have different artifacts than a traditional waterfall process.
• We’ve set expectations with the team and with leadership that agile looks different than waterfall, but it yields better outcomes over time.
• We’ve structured RFPs and SOWs to ensure accountability for a contract matches the needs of agile software development, rather than of a waterfall process.

Play 4 Key questions

• Have we communicated to stakeholders and oversight staff how we’re tracking progress and success as an agile team?
• Are we “solicitation-ready” in case we need to change vendors?
• Is our contract structured to balance the need to maintain competitive pressure on the incumbent, but also to permit time and space for vendors to grow teams that meet our needs?
• Does our contract allow for a discovery and prototyping phase?

The choice between “custom software development” and “customized COTS” is a false one. Very little software is custom-built from scratch anymore. Any effective engineering team will use lots of pre-existing software. Commercial off-the-shelf (COTS) products may promise total solutions, but they’ll inevitably need to be pared-down and customized.

These kinds of architectures allow individual software components to scale independently and are more easily replaced in the future.

Play 5 Checklist

• My service is designed to solve the problems I have today, not the problems I speculate I’ll have later.
• My service is deployed to flexible, commodity hosting infrastructure such as a cloud service provider.
• My service is built on top of primarily open source software.
• My service is not tightly coupled to a particular runtime environment (for example, a proprietary operating system or a complex configuration).
• My service can be deployed and begin taking requests within a month, rather than 3 months or more.

Play 5 Key questions

• Does the government have full control over and access to the underlying data in the system?
• Does our product require developers from one company or a small handful of companies for support, or can anyone support it?
• Are we able to add features as they’re prioritized, or are we dependent on someone else’s roadmap?
• Are we pre-optimizing our system or architecture in anticipation of needs that we’re not currently addressing? Can we make things simpler and evolve them over time, instead of trying to guess what challenges we’ll face in the future?

Cloud service providers offer a fundamentally different value proposition than legacy data centers: the promise of flexible, on-demand resources and pay-for-what-you-use. As changes can be made in moments instead of hours or days, it’s essential that delivery teams be able to manage their systems directly using their preferred tools.

Manually modifying infrastructure, applying regressive network rules, and extended downtime for “maintenance windows” strangle the cloud’s unique advantages and prevent delivery teams from operating effectively.

Similarly, when changes are automated, backed with user acceptance and regression testing, and deployments use best-practices that require no downtime, formally reviewing every change adds needless overhead and slows down delivery teams dramatically.

Play 6 Checklist

• We’re able to create a new environment using our deployment tooling in minutes or hours, not days or weeks.
• We’ve re-tooled our change control board or similar processes to achieve the benefits of fast, secure, and automated deployments.
• We’ve replaced extensive documentation on our deployments with automated logging and auditing tools.

Play 6 Key questions

• Have we updated our security package to reflect our deployment process?
• Are we using a flexible purchasing vehicle (such as time and materials) to allow for easily scaling up and or down (within limits)?
• Does our cloud service provider or cloud platform maintainer impose unnecessary restrictions or limits on how often our development teams can deploy?

Simplicity should be the foundational principle behind both the technology that supports your service and the interface you present to external and internal users.

Choose proven, commodity software for your technology stack, especially for core components. Use technologies that are familiar to the broader web development world, and architect them in familiar configurations. This will lead to simpler, more efficient implementations that are easier to troubleshoot.

Conduct user research, and use those insights to build simple, intuitive interfaces. Without users involved, you can end up with business rules mapped onto a user interface and a service that reinforces organizational complexities. Users have different needs than organizations, and your service should shield them from complex policies and back-end services.

In all cases, an easy-to-understand and easy-to-use interface will help people accomplish their tasks, which helps fulfill the organization’s business needs.

Play 7 Checklist

• We’ve asked if this feature or component is truly needed.
• We use tried-and-true protocols and standards, avoiding overly-abstracted or complicated components that can be brittle, inefficient, or hard to debug in production.
• We use “boring” technologies wherever possible, especially in critical core components such as databases, limiting use of more innovative technology to well-defined experiments where we can contain the effects of failure.

Play 7 Key questions

• Are we relying on extensive documentation to help the user understand how to use our product rather than contextual guides and an intuitive user experience?
• Is it difficult to explain our architecture to someone onboarding to the development team?
• How hard would it be to replace the current delivery team with another team?
• Are we using established, standard technology, tools, and protocols?
• Are we solving problems that aren’t immediately in front of us?

Government processes for ensuring security and privacy compliance can be complicated enough that they have the opposite effect: driving people to make an end-run around these processes just to get things done. This is the worst outcome because it creates incentives for people to neglect both security and privacy.

The right thing to do should be the easiest thing to do. Government leaders should collaborate with technology experts to develop security and privacy requirements incrementally to better align with agile processes and frequent releases.

Your agency can set up generic guardrails and approvals for how user data is handled (such as GSA’s generic privacy impact assessment for design research) rather than forcing a new process on a research team any time they ask a user different questions.

Play 8 Checklist

• We can easily update our Authority to Operate (ATO) package incrementally, using partial assessments.
• We regularly re-evaluate our processes and how our team interacts with them to improve them and encourage the right behaviors.
• We provide usable tooling with security best practices baked in (password managers, one-time use credentials, etc.).
• We maintain a data inventory and don’t collect or retain data that is not essential to the operation of a service.

Play 8 Key questions

• Are we tracking metrics around security incidents that we can use to measure the effectiveness of our current process?
• Are our tools easy to use?
• Can we apply user research and usability testing to make our processes easier to understand and navigate?

If APIs are part of your digital service strategy, then you should treat both internal and external API users just like you would end users of your website.

You need to understand users’ needs and pain points to be able to build something that works for them.

Starting with an API-first approach has many benefits, such as making large, transformational projects more scalable. But don’t develop an API without testing it with other potential users and hope to see any meaningful adoption outside your immediate team. If you build your API in a vacuum, you can’t assume others will be able to use it as well.

Follow the same human-centered design and iterative development techniques you would use to build website features to design and improve your API.

Play 9 Checklist

• Users that aren’t on our direct team are able to find and use our APIs.
• We have incorporated user research on API users into our development process.
• We have a way to capture and prioritize feedback from API users and communicate that priority back to the requestor.
• We have a process for onboarding API users that is automated to the greatest extent possible.

Play 9 Key questions

• How do we communicate changes, outages, or other critical information to our API users?
• Are we allowing users to access their own personal, private data through our API (with proper authentication)?

Too often, government agencies fail to properly align the demand for their digital services with the backend resources needed to support the service.

Try to estimate the expected demand for your service as best as you can. Map that expected demand to a budget for server and infrastructure resources, and plan to have those resources ready for launch.

If you’re already giving your delivery team direct access to the cloud and have a launch plan that includes a gradual migration for users, you’re in a better place to accurately match your resources to real-world demand.

Part of the solution is to build the right architecture for end-user services in the first place. When systems are overbuilt, or built incorrectly for the problem, they must be scaled-up and out of proportion to work effectively. This wastes money and effort and hurts the user experience.

Play 10 Checklist

• Our service is deployed in a flexible hosting environment that can scale automatically on demand without human intervention, like cloud service providers.
• Excess capacity allocated during peak demand times is automatically scaled-down when demand decreases.
• My digital service can scale to meet demands that are typical in consumer internet applications.
• We’ve deployed compute and network resources based on a reasonable estimate of expected demand.

Play 10 Key questions

• Can we put basic analytics on our existing legacy system to better understand our demand profile?
• Do we have data on the upper and lower bounds of potential users?
• How are we compromising the user experience by trying to fit all possible business rules into the same user interface?

Never roll out a new service by abruptly redirecting all traffic to the new system. This practice puts the availability and health of your system at risk while potentially alienating users with little warning about major changes.

Some issues cannot be detected until they’re live in production, no matter how much testing you do in a development environment.

Play 11 Checklist

• We have a well-defined and limited scope for an alpha release.
• We’ve identified well-segmented pieces of the application that are good candidates for initial migration.
• When building new functionality around legacy components, we’ve taken steps to ensure the new functions gracefully degrade and don’t overwhelm the legacy system.
• We have a plan to, over time, decompose a monolithic legacy system into a set of smaller, more focused microservices, centered around the user’s needs.

Play 11 Key questions

• Is our migration strategy oriented around delivering the biggest user value first?
• Is the timing of our rollout dictated by legacy contractual deadlines?
• What are the natural user segments we can target for different phases of our rollout?

Sending systems into a static Operation & Maintenance cycle causes them to become “legacy” systems. When systems enter Operation & Maintenance, they begin to no longer support the evolving needs of their users or interact cleanly with other systems.

While new feature development will certainly slow down or even stop for brief periods in this phase, programs should actively remediate technical debt in their applications to keep them from becoming legacy systems.

Agencies can use fixed price contracts to maintain a smaller cross-functional team that is still able to independently respond to changing user needs and build, deploy, and operate new and improved features. This gives agencies a predictable and flexible way to keep services current without falling into a static Operations & Maintenance cycle.

Even if a wholesale migration is still required in the future, an actively developed product is going to have a much easier migration path.

Play 12 Checklist

• Our team still has an available product owner and maintains an active sprint cycle.
• Our team makes steady progress on remediating technical debt.

Play 12 Key questions

• How difficult is it to add new features or deploy our product?
• Do we maintain a channel for feedback or usability testing, even if it’s infrequent?