Conclusion

Following the principles and practices in this guide will help agencies lower the risk that their technology projects will fail. It’s not easy work, so start small and just try. And then keep trying.

Today, complex technology systems deliver vital government functions that support people’s quality of life. As the launch of HealthCare.gov and numerous other examples show, that function is easily stymied when agencies make ill-informed choices and use ineffective methods to acquire and develop software.

But, agencies can, and sometimes do, avoid those errors and deliver technology systems that serve their intended purpose. They do so by following the principles and practices collected in this guide.

These aren’t new ideas. They are widespread in the private technology sector. They’re not new to government either. Iterative development was used over half a century ago to deliver ambitious projects like the X-15 hypersonic jet, while many technical experts in government, like those on the Defense Innovation Board, know: “modern methods allow a project to continuously improve, adapt to evolving threats, and take advantage of rapid technology advances.” Yet “modern methods” still aren’t the norm in government.

Why? Because we are getting in our own way. In its interim report to Congress, a panel of 16 recognized experts in acquisition and procurement policy wrote of the Department of Defense: “Processes such as developing requirements, contracting, making investments, or obligating money are often driven not by a sound business case, but by arbitrary deadlines and outside pressures.” It went on: “Both written rules and performance norms incentivize making decisions that lead to suboptimal outcomes.” The Department of Defense is not alone in its troubles. Policies, processes, and cultures that are resistant to change are common in government agencies.

Often this resistance is due to the weight of “outside pressures” that are beyond their control. But, what we can control as public servants is choosing to approach government technology projects differently than we have in the past and acting on the knowledge that traditional attitudes and methods don’t work and organizational inertia is harmful. You can avoid “suboptimal outcomes” by applying the methods, tools, processes, and recommendations in this guide.

This work is not easy, but it is possible and it gets easier the more you do it. If you’re struggling to figure out where to start, try beginning with a small project or small piece of a project. Or try using one method on a current project.

The important word here is “try.” Adopting new practices and cultivating them within an organization takes trial, error, and time. Don’t expect instant success. Each “mistake” will be a learning moment and opportunity to try something different. Legacy practices will likely coexist with new ones for a while. Celebrate small wins. Find champions of change and work together. Adapting to using iterative software development requires agility and openness in your attitude as well as your practices.

The real challenge is not following the practices in this guide. It’s doing so again and again. Software is never done. It needs constant “care and feeding” so that it continues to work for people and our changing needs. The most difficult work is the commitment to doing the work despite its challenges.