This playbook is for agencies ready to replace enterprise software patterns with proven techniques from the world of commercial software.
Follow these plays to better equip your team with the practices that create resilient, flexible, and customer-friendly digital services.
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.
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.
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.
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.
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.
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.
Cloud management teams are a relic of the legacy data center era.
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.
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.
Simple services start with proven software and intuitive interfaces.
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.
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.
Privacy and security must be baked into all parts of the digital service, just like usability and scalability.
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.
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.
Don’t build your API in a vacuum.
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.
Too often, government agencies fail to properly align the demand for their digital services with the backend resources needed to support the service.
Estimate demand + map to resources + plan for launch
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.
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.
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.
Legacy systems are the inevitable result of a lack of capital investment.
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.
Special thanks to Kaitlin Devine and Paul Smith for writing the original version of this playbook.
Work with Ad Hoc to take the next step in becoming an agency that is excellent at building, deploying, and scaling digital services.