For the past five months I’ve been working with the U.S. Department of Health and Human Services (HHS) as an External Entrepreneur on the Building a Design-Minded and More Collaborative Office of Family Assistance Project at the Administration for Children and Families. My work is part of an HHS “innovation fellowship” that brings traditionally private sector people who have entrepreneurial experience into HHS for 13 months. It’s already been a rewarding experience for me: I’ve learned a great deal and I’ve felt valued for my contributions. I’d like to further reflect on my experience later, and for now I want to write about an issue I’ve come across a few times, that my colleagues at HHS encouraged me to write about: the importance of product skills in technology procurements.
Until I moved to California, I didn’t really know what it meant to have a “product skillset.” Essentially it’s a cross-disciplinary background that spans business, technology, and design. Amongst other things, it helps one to prioritize the requirements and features when building a product. Someone with a product skillset (a “product person”) can be especially helpful in the early stages of product development: they can balance the business needs (solving the problem), the technical complexity (how long it can take, what it should cost, what portions can be built)) and the end user experience (how likely the user will be to use / benefit from it). A holistic product perspective can significantly reduce the risk and focus the scope of a technology initiative. And I believe the federal government could use more people with this perspective. To illustrate that belief, I’ll walk you through the technology procurement process.
Note: I have only moderate experience with government contracting, and the details of what I’m about to describe are not universal. However, the following will apply to many technology procurements. I *have* been a government contractor for many federal agencies over several years, so please don’t assume that all my issues below are from four months at HHS! In my experience, a technology procurement for the federal government follows this process:
- A problem is identified.
- The requirements that will address this problem are determined or drawn up.
- Outside vendors bid to address these requirements.
- The agency selects a vendor.
- The agency and vendor work together to build the product.
This may seem like a reasonable way to build a product. Unfortunately, the business, technology, and user needs are not taken into consideration at all stages. Let’s look more closely:
1. A problem is identified
A problem can be identified by a number of different internal parties or external events. Some examples:
- Management could identify a problem that affects their staff
- Staff could raise an issue of their own
- Congress could pass a federal mandate
- Deploying a new technology infrastructure could have unforeseen effects, some of which are sufficient to merit other new technology projects
- A world event could create an emergency
As you can see, at this first stage there may already be a barrier to the product’s later success—the people who will ultimately use this new tool may not believe they have a problem or have interest in changing their behaviors. Regardless of who identifies the problem, it’s important to interview and work with the users who are impacted as quickly as possible.
2. The requirements are determined or drawn up
In my experience, one of three groups will draw up the requirements:
- A technical group (“tech group”)
- The end users who will ultimately use the solution (“end users”)
- A group that is building a tool for their customers/staff to use (“managers”)
However, all the groups should be involved — the users should be interviewed and a tech group consulted. If there will be managers involved in administering it, their voice needs to be heard, as well. In my experience, these groups don’t come together enough. Once I worked with a group of managers that had spent a great deal of time building a prototype and detailing a comprehensive set of specifications. However, they neither interviewed the end users prior to building the prototype nor consulted the tech group to gather the constraints of their technical infrastructure. Generally, the technical group doesn’t know the best solution for the end users/managers (for simplicity, I’ll refer to both together as “users”). Or users don’t know how the technology can address the problem. Yet in either case, whichever group draws up the requirements, they’re expected to describe not only what the problem is but exactly how to solve it. Here’s where a product person can help:
- Prioritizing for cost/timeline: They can identify which requirements are particularly expensive or time-consuming to build, and then work with the users to see whether they’re really worth it.
- Simplifying for user experience/adoption: They can examine the proposed solution and identify where workflows are needlessly complex, where manual steps could be automated, and generally where there are potential barriers to adoption
To be clear, this process does not need to happen completely within the federal agency. It’s often better to get an early perspective from those who might ultimately build the solution. Even through Requests for Information and planned Q&A, a product person can help get everyone on the same page by serving as a technical translator and focusing the conversation. When done right, this can simplify the scope, shorten the timeline, and ultimately lead to a more useful product.
3. Outside vendors bid to address these requirements
At this point, the primary objective is to find a vendor who can meet the requirements. If the requirements lead to a product more complicated than necessary, there’s not a strong incentive for the vendor to simplify things in their bid. Furthermore, if the vendor doesn’t submit a plan that addresses the requirements exactly as they are stated, they probably can’t win the bid. There is a chance for Q&A, but not a chance for the most important question that a product person would ask, “is this the best product to build?”
4. The agency selects a vendor
This is a very careful and well-documented process, because if it’s a large procurement then there’s a good chance there will be a protest of the decision. Points here are awarded for checked boxes, not out-of-the-box creativity.
5. The agency and vendor work together to build the product
Now the user and the vendor really come together to work on the product. Often this is the first time that product people (from the vendor) get to communicate directly with the user. At this point, a good vendor can determine if the product being built will address the user’s needs. Unfortunately the scope and timeline have already been defined, and the funds already committed. It’s not an easy time to be flexible, and I believe this is a big part of why only five percent of large federal IT projects are successful (according to a recent study by The Standish Group).
Introducing Product People Earlier into the Process
I don’t mean to be just one more person to point out issues with the federal procurement process. At HHS, I’ve seen firsthand that the people writing up requirements are competent and motivated to build the best products. I also don’t fault the vendors for playing their role in a system that they’re a part of. Rather, I think the system is disjointed. While the vendor may bring product expertise to the table, they are not involved early enough to ask the difficult questions that could dramatically affect the project scope. By the time they’re involved, the budget is already set, which limits the incentive to propose a simpler product. Instead, the government should employ their own product people, and involve them in the early stages of every sizable procurement. These people would spend time working directly with the users to validate assumptions, perhaps even creating prototypes to test assumptions. By the time a solicitation is announced, the business, technology, and user needs should already be relatively balanced and prioritized. I believe that with product expertise early-on, not only will technology projects be more successful, but their scope will be reduced from the beginning. A strong product manager won’t try to “boil the ocean” (as so many procurements do) but instead will focus on getting the product into the users hands sooner than later with a set of requirements more interested in progress than perfection. I know this is all easier said than done, and that much progress could be made by changing the existing process:
- Involving the users at every stage would help to maintain focus on solving the most pressing problem.
- Focusing the requirement documents on solving the problem rather than how to solve the problem would give the vendor an opportunity to innovate and perhaps even suggest much simpler solutions.
Still, hiring strong product people would more realistically change procurement than by training the existing staff in the myriad of skills that product people bring to the table. Further, product people would enjoy the opportunity to work for the federal government: being a product person on a large-scale project is a somewhat unique chance to reach millions of people, to significantly reduce government spending, and to make our country run more efficiently. I’ve thoroughly enjoyed lending my own product skills to procurements at HHS, and I believe others would welcome similar opportunities.