Navigating digital acquisitions

Many of us have heard the term “agile acquisition,” but what does it look like in practice, and why is it better for digital modernizations?

Agile acquisitions are structured to reduce risks while ensuring that each solution meets a user’s complex needs throughout the web modernization process. Contracts often focus on the technical system behind the website. You may see these types of contracts involved in website modernization approaches. Typically, they begin by gathering requirements. However, if we are to change the user experience we must begin the process another way. During this phase, figuring out the problem you are trying to solve and the product (website) vision followed by user research is key — you want to ensure the assumed audience and problem is correct. User research is especially important for web modernization projects because websites are a primary way that the public interacts with the federal government.

Build versus buy

Once you’ve completed user research, you face two potential avenues for procurement. You can decide either to build or buy something. The user research can help de-risk this decision. By surveying the market against user needs and pain points, you can better decide if there are existing solutions that either solve most of the user needs or if you will need to custom-build to satisfy the user needs.

Building in digital modernizations

If you decide to custom create your modern website, there are a few actions you can take to ensure success. First, structure your work statement for agile collaboration by using a statement of objectives. A statement of objectives states the overall performance goals of a project and is often used in solicitations to give vendors flexibility to propose creative approaches. This is sometimes confused with a statement of work, which outlines the details of a project, including tasks, timelines, deliverables, and success criteria. A statement of work is best suited if you have decided to purchase an existing solution (such as commercial off-the-shelf, low-code, or no-code platforms). When considering a third option of a “blend” of customization and integration of existing solutions then a Performance Work Statement is often best suited.

Consider using a time and materials contract type for custom development, which gives the government flexibility to control the amount of work via user stories provided through an empowered product owner. The government product owner controls the user story backlog (a prioritized list of work to be done), which constrains the cost but allows the government to easily pivot when a new user need arises. On the other hand, consider using a firm-fixed contract type for existing solutions, and a hybrid for a blend.

Next, ask potential vendors to showcase similar work they’ve done in the past by requesting access to code repositories that your team could analyze. You will want some experts on your team (like a software engineer or developer)— or at least informed decision makers who are able to read code repositories — to perform this code review and validate whether the code and repositories demonstrate best practices. For existing solutions, consider requesting sandbox access to have a handful of users perform usability testing for major tasks/functionality to evaluate whether potential solutions are viable and meet your needs.

After awarding the contract, these teammates will judge work quality based on a Quality Assurance Surveillance Plan, including accessibility requirements. They’ll also track the vendor’s progress on the build of your website through fundamental agile activities and meetings like backlog refinement and sprint planning. While these surveillance plans are best suited for custom development, there are elements you can use for your existing solution, including accessibility, usability testing, and user research.

Buying in digital modernizations

As stated, there may already be a product on the market that could meet your team’s needs.

In that case, you might opt for the second procurement option: buy something. This usually means buying commercial off-the-shelf products. When you buy a product off the shelf, it’s important to understand the difference between configuration and modification:

• Configuration involves using a solution’s built-in settings and tools to change its features.
• Modification (sometimes called customization), involves actually changing the solution’s core code to change its features. This is more complex and typically requires specialized development skills.

While you’ll configure anything you buy to your agency’s requirements, avoid going into a purchase with plans to make dramatic modifications. Buying off the shelf and modifying requires a lot of time and money. Plus, customization of existing solutions can cause further vendor lock-in. This is why it is important to ensure the solution meets user needs before purchasing it.

The process for selecting products you may want to buy begins with defining your problem, product vision, and conducting user research to understand the needs and pain points the product is intended to solve for. When buying a solution, use the research to conduct market research differently by using:

• A statement of work (PDF, 130 KB, 21 pages) as your work statement
• Usability testing and scorecards (such as the Accessibility Conformance Report and Voluntary Product Accessibility Template) to gauge how well a product meets your needs for function and accessibility

Instead of receiving demos to evaluate a product’s applicability to your need, performing usability testing with real users can offer insight into whether a potential solution meets your needs. Ask potential users to perform their regular work with the tool to determine in a hands-on way whether it operates and meets their daily needs well. Finally, firm-fixed-price contracts are typically used when purchasing commercial products with detailed and definite specifications and quantities. These types of contracts provide maximum incentive for the contractor to control costs.

When buying commercial off-the-shelf products, consider the Federal Risk and Authorization Management Program, commonly known as FedRAMP. This program was created to provide standardized security processes and requirements allowing agencies to rapidly adopt cloud service offerings. Many commercial products are not compliant with federal security requirements.

Browse the FedRAMP Marketplace to find authorized services. Also, consider whether this requirement will decrease competition as advised in the FedRAMP frequently asked questions.

Budget is a common challenge to agile acquisitions. If you have a smaller budget, a minimum viable product (MVP) is a good place to start and build agency buy-in. This is useful whether you decide to buy or build.

To develop an MVP, conduct an assessment of key technical requirements and user needs, including the price and budgetary constraints. This assessment will help stakeholders focus on the requirements they truly must have in a solution. Use these requirements to develop an MVP. As your agency’s leadership sees the visual representation of the product and reviews the honest and accurate calculations, you might receive additional funds. Throughout this process, it is important not to be overly optimistic, to overpromise, or to pack your sprints with more work than can be done.

What can I do next?

Regardless of your decision to build or buy, factor long-term maintenance into your budgets and plans. Develop an understanding of what it will take to maintain your solution over time and plan your budget accordingly. Think about sustaining your solutions throughout its entire life cycle. Also, consider the amount of scalability you will require in the long-term.

For more information on how to jump start your approach, check out the 18F De-risking Guide.

You can also join a Digital.gov community of practice to connect with fellow web and digital practitioners in government who are working to create better online experiences for the public.