Dear agency senior executive: You can make or break your next big tech initiative

You are a senior executive of a government agency. You are devoted to your mission but your organization has challenges that include legacy technology, cumbersome processes, and funding constraints. An inflection point looms, instigated by a period of performance termination date, legislation, policy, or an outdated system. You may have heard that modern principles can help you reduce risk on projects like yours, but changing the way you work isn't easy. 

You don't want to perpetuate problems rather than solving them, undermining the success of your own initiative. Without knowing how to manage a modern software development project, leaders in your position often default to existing processes, decision making methods, and expectations for success, all while "the playing field is changing." You are not alone — this situation is relevant to many agencies and Congress, as seen in recent Senate Committee hearings.

Your approach to your next big tech initiative needs to be dynamic, not static. You need to respond to change as user needs mature, the security landscape shifts, and organizational priorities change. When any challenge arises, you must first build a shared understanding with your team, then decide and act. 

How do you do that, in the real world? Use these recommendations as a starting place to learn how we've worked with agency leaders like yourself to support teams, mitigate risks, and help ensure success. 

1. Pursue the smallest scope of work with the fewest amount of people. 

Reducing the scope of a feature as much as possible before building it mitigates risk, especially when the challenge is complex or uncertain. Avoid pursuing the biggest, "flashiest" part of a product first—that will just increase risk and scrutiny. It's better to build trust by delivering updates, regularly and consistently.

Beyond reducing scope, it's important to minimize the layers of communication down to two groups: a cross-functional product team and a group of champions. This will enable a tighter feedback loop between strategic decisions and user feedback. Otherwise, more time will be spent justifying the work rather than doing it.

A cross-functional product team ideally consists of five to nine people with the user research, design, content, software development, and/or security skills necessary to get the job done, along with a product owner to prioritize and organize the work. A small group of champions should consist of four to five senior executives, with organizational, financial, technical, human resource, and program expertise.

Frequent direct interactions between a product team and champions will encourage a relationship based on expertise, not authority. The product team should be conducting user research regularly and leveraging that information to direct all product decisions. They should then update the champions every sprint (via weekly ship emails and monthly demos), so that the champions can advise on the best path forward, given their knowledge of organizational enablers and risks. 

2. Spend a little in the short-term to build confidence in long-term tech decisions.

Senior executives are forced to plan and budget far in advance. These long-term planning and procurement processes often prematurely finalize big decisions for critical systems before they are tested and validated. By working in shorter time frames, senior executives and tech teams can reduce risk. Senior executives are in the right place to move organizations and make the incremental investments that will create conditions more favorable to sustained success.

Instead of buying and building a new system right away, have a tech team spend 4–6 weeks prototyping a solution with a real use case. This will enable you to test out criteria or critical functions. Focus on 1–2 specific use cases in order to test with real data and critical scenarios, for example: 

• For beta.ada.gov, we created a prototyping environment using the US Web Design System to test the feasibility and impact of redesigning their content
• For the Justice Department's knowledge management system, we tested the entire content governance process of writing, formatting, reviewing, editing, and publishing using travel guidance as an example, in order to compare our two options – a custom, static site and Sharepoint

Give the agency more control when building a solution by using a time and material (T&M) contract. As noted in the 18F De-risking Guide, a traditional government fear of T&M contracts is that costs spin out of control, but an empowered product owner and team can reduce this risk through frequent communication and inspection of performance against a quality assurance surveillance plan (QASP). 

3. Use stories as leading indicators.

Senior executives seek metrics to easily monitor a project's progress. Often they get reports on productivity metrics such as time, cost, and velocity, because they're easy to quantify and standardize. However, productivity doesn't guarantee success — a software project is only successful when it delivers value to end users. Quantitatively measuring user success would be ideal, especially at the scale of government agencies and their services – but that has proven to be difficult.

Stories that demonstrate current problems, the product itself, and reactions to the product are better leading indicators of success than metrics. Stories provide genuine and nuanced insight. This includes quotes from interviews observing how users use the current system, recordings of how the product is being built, or reactions to new functionality. Demos not memos; show your progress, don't tell. Stories like these bring to light patterns and common challenges that you can prioritize and then develop a better roadmap for your product. 

For more detail on these recommendations and more, see our series of posts titled Senior executives are the allies tech teams need.