I’m at the Code for America Summit this week in Oakland, CA, gathering with hundreds, if not thousands, of amazing people who are all united by a passion for making government effective in serving people. This is my fourth time at Summit, and I’m looking forward to learning about all the amazing work going on in so many places. Last year, I spoke at Summit about the role of vendors in government technology, and what the community could do to help make vendors more effective in fulfilling our role in the ecosystem.
This year, I’d like to continue that conversation on vendors and the role that we play. I believe wholeheartedly that vendors are a critical part of the solution that leads to a government that is confident in using technology to be efficient, effective, and responsive to the people it serves.
Government technology organizations have proposed a number of different solutions to improving government procurement of technology. Some focus on improving the proposal process by shifting from written proposals to a technical demo or prototyping exercise, which requires a vendor to demonstrate that they can actually develop working code. Others focus on restructuring how procurements are organized, shifting from a systems integrator approach to a more modular way of engaging vendors to collaboratively build a system. And others focus on revamping how delivery is managed, moving from a waterfall approach to a more iterative, agile approach that allows for incremental delivery of features and makes room for learning and adapting to change.
Each of these solutions has some merit (some more than others, subjects of future blog posts), but they all seem to address only part of the challenges in implementing technology solutions. My theory is that a more relationship-based and holistic approach would better enable the government and the users they serve, than the seemingly distant and transactional relationship that appears to often exist in traditional procurement.
When I’ve seen government projects go wrong (and I’ve seen some stuff), root cause analyses often end in one place: procurement. Invariably, the government tried to do something that required skills and experience that their market of vendors did not possess. The result, as we’ve seen so many times, is a failure. I’ve seen this happen even when the above innovations in how vendors are selected, how contracts are organized, and how delivery is managed were in place. Even those things will not protect against hiring a vendor who just doesn’t have the appropriate experience for the problem at hand.
Fortunately, the government has tremendous power here, but it takes some work. Agencies should start with identifying the outcomes that meet the needs of the people they serve, then cultivate relationships with vendors that have a track record in enabling those outcomes (with the help of digital services teams like USDS and 18F to guide them). If the skills, processes, and technologies necessary to achieve an outcome are new to an agency, we all have to acknowledge that it will take time. And, if vendors are smart, they’ll want to start small, and get to know an agency. They will learn about an agency’s business, how they’re organized, and what additional skills they can develop to better help their customers achieve successful outcomes. And for customers and those they serve, iterating on small successes with a trusted vendor partner is almost always faster than making big bets and hoping an unknown vendor can deliver.
A recent example
I spoke recently with a government agency that was in the midst of a crisis. They had put out a Request for Proposals looking for a sizable team to come in and do agile software development and DevOps. The project focused on the infrastructure of a legacy system, and required extensive knowledge of the existing systems and the business processes surrounding them.
While I really wanted to help this agency, I told them that I didn’t think we were right for the approach they were taking. We had never worked with this agency before, and did not know much about their systems, their business processes, and their users. We didn’t have a good idea of their capabilities. This all stemmed from the fact that we didn’t have an established relationship with them. What I suggested was a small team focused on digging in, understanding the problems, with the goal of making incremental progress, instead of dropping in a team of 15 people. While I was sympathetic to their urgency, the biggest challenge to me was the fact that they didn’t have established relationships with vendors that understood them, their capabilities, and could immediately help.
When it works
Where I’ve seen our work really develop into something amazing are situations where we’ve started small with agencies. These agencies have wanted to do something new: adopt new processes or technology, take a user-centric approach to delivering services. We start small with them, and grow together as we learn more about their business, and most importantly, their users. And we invest in helping them by building a team of people that grows to deeply identify with and understand their mission.
This is how we worked with VA, starting with a small proof of concept prototype called Vets.gov, and in two years of working closely with the agency, were able to transition it to power their main web presence, VA.gov. This is also how we rebuilt HealthCare.gov, starting with a small application that solved a very specific problem, supporting and evolving it as it grew over time to eventually encompass the entirety of the user-facing experience of the federal marketplace. I hope this is how we’ll work with other agencies to transform how they deliver services and meet the needs of the people they serve with technology.
In all of these engagements, the determining factor was the relationship. We grew and invested in our customer, and our customer in turn invested in us, and together we were able to accomplish not just small wins, but outcomes that literally transformational for the agency.
I have more thoughts on how agencies could implement this practically, which I’ll write about soon. The restrictions around government contracting make some of these changes difficult, but not impossible. The good news is that the government is in a tremendous position of strength here, with the ability to create a market and cultivate relationships with vendors that have the skills and experience they need. This is, in my opinion, critical to improving the outcomes we see from government technology endeavors with vendors.
