Federal Contracting Part 3: The Definition of Madness

There is a common assumption in government IT services procurement that past experience is an indicator of future success. But, when working with an industry that benefits mostly from the efforts of individual performers, the idea of ‘corporate’ past experience is a logical fallacy. Not only does it put the government at an immediate disadvantage, it favors repeating inefficient activities that benefit large contracting firms rather than promoting the innovation needed to move into new technology areas.

This is Part 3 of my Federal IT Contracting series. Please be sure to check out my Introduction posting that includes a disclaimer about my past relationship with CGI Federal, the primary contracting firm responsible for the Healthcare.gov project.

I recently saw a job posting that included a requirement that the candidate have over 6 years of social media experience. Here’s some perspective on what the ‘social media’ landscape looked like in 2007:

• MySpace was considered the leader in the market space, with the highest traffic and over 100 Million accounts, according to Wikipedia.
• Facebook was about a quarter the size of MySpace in users and was just in the early stages of supporting social gaming.
• LinkedIn was confined to the US market with about the same number of users as Facebook.
• Twitter had just spun off as an independent startup.
• Google+ was four years away from its initial ‘invitation-only’ release.

In the six years since, social media has changed substantially, morphing into a new sales and marketing channel that is still incompletely understood. Companies routinely fail in their social media campaigns, sometimes even eliciting severe blowback in response to their efforts. Does the company that posted the job description really think that experience with MySpace has any real impact on an individual’s potential for success today?

The government behaves in the same manner. In my research, I found two sites that seem to convey the key requirements for the Healthcare.gov effort. Here are some key entries:

• “Content Requirements for Healthcare.gov - HealthCare.gov is the first central database of health coverage options, combining information about public programs with information on more than 8,000 private insurance products. Consumers can review options specific to their personal situation and local community. The website connects consumers to quality rankings for local health care providers as well as preventive services. In addition, it explains the provisions of the Affordable Care Act.”
  
  “Health Care Reform Insurance Web Portal Requirements - The Affordable Care Act requires the establishment of a website through which individuals and small businesses can obtain information about the insurance coverage options that may be available to them in their state. This interim final rule specifies the categories of information that will be collected and displayed via the website, and the data required from issuers and requested from states, associations, and high-risk pools in order to create this content.”
  
  Retrieved from here on December 7, 2013.


• “In implementing [Patient Protection and Affordable Care Act] requirements, we seek to develop a website…that would empower consumers by increasing informed choice and promoting market competition.”
  
  Retrieved from here on December 7, 2013.

So, the government was looking for a web site and a database. That doesn’t sound so bad. While I can’t find the original Healthcare.gov solicitation (more on that a bit later), I’m sure that it included more depth around what the site should do.

There’s nothing new about procuring a web site and accompanying database. The government does that all the time and contracting firms have a lot of people competent in building either. All a firm needs to do to bid on this kind of work is come up with a few examples of past projects of similar scope and scale, perhaps bring in a partner with the ability to build the infrastructure, and then run for the job.

Except, Healthcare.gov isn’t just a web site. Behind it is an incredibly complex integration and messaging platform, one that would need to coordinate with systems in 50 states, several other territories and districts, and thousands of insurance companies. I would consider that effort to be the most ambitious IT endeavor ever attempted by the US government, perhaps by any organization. So, how can a firm’s past experience in deploying large web sites be any logical indication of future success on this project?

I argued in a prior post that firm past performance is less important than the experience and skills of the individual contributors. In my experience with big firms (including my time at AMS, the precursor to CGI Federal; See disclaimer in my Introduction to this series), business groups seem to form more of a loose confederation than a consolidated firm entity. Managers on one side of the business often must be told to work with those on another side. Even worse, managers in one group may actively compete for business against others in the same group. When bidding on work, a firm will cull the best past performance examples from any of its business units. But, without the people who actually did the work, those examples culminate in nothing more than a promise that the firm knows what the government is asking for.

I have also argued that those individuals who succeed the most at solving problems are the ones who struggle the most in the business simply because mediocrity is more profitable than excellence. Those select individuals who realize that firms will simply use them to build enough legitimacy as to continue winning work will eventually become disgruntled and leave the firm. This turnover should have a negative impact on a firm’s past performance, but there’s nothing in government IT services procurement that says people who were part of a successful project still be with the firm, much less that they be involved with the new project. Perhaps, in addition to asking for past performance, the government should also ask for turnover metrics associated with the people involved on those projects.

Where do good people go when they leave a firm? They can go to another large firm, but I argue that the conditions at one large firm will be no different than at another. So, after trying that move, good people often seek the independence that can come from being at a small firm. I’ve made both moves and have seen many former colleagues do the same. Since good people tend to attract other good people, there are many small firms that have broken out of the mediocrity market. It’s just too bad that the procurement deck is stacked against them.

This brings me to the original Healthcare.gov solicitation and why it doesn’t seem to be available online. It’s not available because it was never open for public bidding. Instead, the Centers for Medicare and Medicaid Services (CMS), the bureau under the Department of Health and Human Services (HHS) that managed the procurement, sought responses only from a group of 16 companies that comprise the Enterprise System Development (ESD) indefinite delivery, indefinite quantity (IDIQ) contract vehicle.

The government rightly uses IDIQs to intentionally restrict bidding and ease the evaluation process. After all, if every solicitation had hundreds of potential vendors, nothing would ever get procured.
ESD participants read like a who’s who of big IT contracting firms: Northrup Grumman, Lockheed Martin, IBM, SAIC, and CGI Federal, just to name a few. (Go here for the full list) By restricting the solicitation to the ESD IDIQ, the government not only reduced the Healthcare.gov bidding pool, it essentially isolated the procurement away from those small companies that are gathering all those good people that the government wants working on the project, those whose work forms the basis for the past performance used by the bidding firms.

What’s even worse is that the contract vehicles like ESD isolate the government away from innovative emerging companies. Originally issued in 2006, CMS awarded ESD in late 2007. So, by selecting that contract vehicle as the pool from which to select potential bidders, the government restricted its options to companies that proved their IT worth back when MySpace was the top social network. How could their qualifications then possibly apply to a contemporary healthcare exchange when they had no experience then with the technologies that apply now?

The firms that bid on the ESD vehicle did so before the iPhone was released, before cloud computing, before big data. By restricting the pool to ESD participants, the government failed to consider those large and small innovative companies that are considered leaders in key IT areas related to Healthcare.gov.

When conducting major IT services procurements, the government starts from behind every single time. It’s no wonder why it consistently fails at executing on them.