Part 8. Our teams are, by nature, part full-time government employees and part contractors.

The architecture of our teams

Having a broad complement of full-time software developers and product managers is critical to leading an organization that operates as a product team. At the same time, we recognize that federal tech resources are in scarce supply in the market, and the technical landscape changes more quickly than the traditional government employee pipeline can accommodate. While we seek to increase the number of full-time technical staff in OIT, our efforts cannot match our demand for tech talent. Our scope spans over two thousand locations, a thousand systems, and over a half million users. As a result, we will continue to depend heavily on contractors to deliver on our mission, and we embrace them as members of one team. To do this effectively, we conduct project reviews and planning jointly. We are clear on who is responsible for what, and we work together to continuously improve our technical rigor as a single Product Group at VA.

Contractors as a critical component of the IT Product Group

The government often gets into a mindset of shielding contractors from meetings, decision-making, and performance review; this is a mistake. When you think about the structure of most product and development teams within the commercial space, they act as a single team. We also must do this in the federal environment, even though a lot of our work is outsourced.

Operating as a single team still means we must hold our contractor partners accountable for their portion of the end result and how they do the work. By doing so, we get better incrementally and bring forward the issues they face. We expect them to develop ideas on making process improvements, thereby getting into a rhythm of continuously improving. As a measure, if we don’t know the names of the contractors, then we aren’t getting a balanced view because we don’t hear those voices. If we aren’t hearing from their leadership on what is going well and what isn’t, then there’s an important voice missing from the conversation. So, again, we must act as one virtual team, with all members performing their job.

Of course, this doesn’t mean that we mistake purposeful inclusion for blanket participation. It’s not always appropriate or ethical for contractors to participate in decisions and planning that would give them an unfair advantage during competition for a contract requirement that flows from privileged conversations around planning and decision making. Careful coordination with the Contracting Officer and Office of General Counsel during both the contract planning and post-award stages is critical to mitigating these risks.

At the same time, we must recognize that they are contractors. Just like our full-time employees, the government must take action if the contractor is not performing well. It’s a delicate balance of acting as a team and holding contractors responsible for their work. We in the development teams and in Strategic Sourcing do this by having candid conversations with their leadership and by documenting contractor performance, reflecting on how well the contractor performed on past work and whether we would want to work with them again in the future. Every time VA conducts a Federal Information Technology Acquisition Reform Act (FITARA) review, it serves as a gate as we consider how well the contractor has performed before continuing our partnership.

My past experience working on the team that recovered from the early failed effort of Healthcare.gov illustrates the importance of operating collectively as one product group and ensuring performance-based accountability at both the government and contractor levels. Originally, everything was farmed out to multiple contractors who were each responsible for delivering individual pieces of the larger system. Each one believed that their individual pieces would “magically work,” despite the immense complexity and scope of the system. This led to a lack of accountability and a reluctance to work together to solve the problem when those individual pieces resulted in a dysfunctional product. During the recovery, we forced the teams to act as one composite team, problem solving together as one.

This project also illustrates why a great full-time system architect is so critical. If you’re contracting several pieces out, you need an architect with deep systems development experience who can ensure that you have a solid system design to begin with, assess the technical roadmaps chosen by the teams, identify the problems before they explode, and ensure the teams are working together in harmony towards the same goal.

Don’t use contractors as a crutch

In most cases, I believe it’s a mistake to contract out top-level strategy work.  It can be supported by contractors with specific knowledge and insight, but in the end, the internal teams are the ones that know the environment best and will be on the hook to deliver results for stakeholders, policymakers, and taxpayers in the future. They are going to be the ones who lead the organization through implementing the strategy, and they need to have been intimately involved in its creation and the development of the implementation roadmap. They must be passionate about that role, understand it well, connect it to the strategy, evangelize it, and communicate to stakeholders. That just can’t be outsourced.

The value of contractors is, instead, to leverage them to dig in and do independent assessments in areas that we don’t have the full-time capacity or the independent perspective to do. But if we use them in this way, we need to be sure that the questions we’re asking them to answer are ones that we truly can’t live without the answers to – e.g., don’t ask them to do a complete industry assessment when we know that we really only have two feasible options. In fact, don’t use them at all until you believe you have the problem well framed and the critical questions identified.

Innovate on your contract vehicles

The government relies heavily on contractors to accomplish the mission. This necessitates rigorous evaluation not only in ensuring that we’re using the most appropriate contract vehicles to satisfy the business need, but that we’re making contract selections in the right way—both areas that are ripe for innovation.

This demand for contract labor has created a vast, lucrative marketplace for vendors.  Amid all this choice, it can be difficult for the government to align the right contractor solution to the government’s requirement. Cutting through the marketing pitches of contract proposals in order to evaluate the feasibility of their approach can be difficult, and that’s why you sometimes see proposals that make sense on paper but reflect a different reality when it comes to execution. At VA we utilize a “show me, don’t tell me” evaluation approach. Instead of long written “book reports” or other static proposals that do not directly reflect how a vendor delivers, we review real work products and processes demonstrated by vendors in response to a fictional problem. Alternatively, we’ll competitively award a small project to a promising contractor to see how well they deliver. Both approaches provide us confidence that the vendor is capable of delivering high quality solutions in support of our Veterans in a way that aligns with OIT’s working principles of engineering excellence and with a focus on the customer and user experience.

We review the past expertise and experience of the vendor. This includes the review of case studies, project artifacts, and live products, delivered by the vendor during previous projects, allowing us to separate the “fakers” from vendors who truly specialize in digital transformation and agile delivery.

We also ensure that we contract for systems “in increments.” If a contractor is not delivering, there is always an “Optional Task” or “Option Period” milestone coming up where we can reconsider whether to continue the relationship. This is particularly important in major modernization projects. We’re increasingly defining contracts with a series of incremental deliverables that avoid “big bang modernization,” where the entire system is bought as a single, fully deployed system. Instead, we’re focusing more and more on delivering the MVP (Minimum Viable Product) first, validating it meets the goals, and scaling with success.

Veterans can only receive the benefits and services that they deserve when VA has a strong partnership between government and contractors delivering modern software products.  This doesn’t happen by accident. In response to tough labor markets, tight government resources, and the ever-changing nature of the IT problems that  we’re trying to solve, we lean heavily on a growing contractor workforce to modernize our software products. As we continue to innovate around these acquisitions to ensure the government is maximizing value from taxpayer dollars, we must also not slip into the old way of thinking—that you can purchase a little help from here and from there and then put it all together for a working product. The complexity of our systems and software requires a mindset where the government and the contractor workforce operate as one team, and both are held accountable for the product’s success.