Federal Contracting Part 4: Intervention and Rehab

The challenge faced by HHS and CGI Federal to build Healthcare.gov were exceptional. They attempted to tackle an extremely complex data integration and communications platform in the relatively short timeframe of just under two years. Even without the highly charged political environment that hovered over the project, threatening to rain down at every moment, I would consider the project to be as ambitious as any government IT project has been. Add to that the directives and regulations that the project had to be managed against and I would have though initial success to have been an improbable expectation.

This is Part 4 and final post 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 don’t think that it would be completely fair to compare the effort against some hypothetical example of how the private sector would conduct the project. There’s a level of defect acceptance in private sector deployments that doesn’t exist in similar public sector exercises; citizens do not tolerate problems like consumers do. Rather, the government can and should learn some key lessons from the failed initial Healthcare.gov roll-out.

1. Eliminate the “Big Bang”
   The government is infatuated with the idea that IT projects be huge and that they culminate in one large release after a whole lot of effort. It’s a nice romantic notion that everything done one way can be suddenly changed and improved with the flip of a switch, but that ideal result is almost never realized. Healthcare.gov demonstrates the high risk of this approach and how easily it can go wrong. Contracting firms are also enamored with this approach because it favors their ability to realize long-term revenue streams that have a high potential for increase value and up-sell as requirements change and inevitable roll-out challenges cause the work to be extended.
   
   By following the private sector’s lead and defining IT project scope more incrementally, the government would gain greater control over project execution and swing the advantage back to its side from the contracting firms. It could scope releases in such a way as to reduce functional delivery at any one time, allowing the government to identify potential issues earlier in the project development cycle and granting project managers the opportunity to better adapt to changes as they occur. This enhanced approach would expand competition by reducing the advantage that large contracting firms have over smaller firms, promoting greater cost efficiency and innovativeness. Also, the government would reduce overall risk by gaining the ability to halt a project while still receiving some limited benefit.
   
   Unfortunately, the government is poorly suited to support this approach. I wrote previously about the challenges that the government has with implementing incremental development from a security compliance perspective, and those challenges extend to agency procurement and contracting processes. But, the most critical challenge is probably budgetary. As Congress generally appropriates money for IT projects well in advance, it forces agencies to plan IT projects 3-4 years before even starting the work. Agencies need more fiduciary flexibility to empower them to respond to IT environment changes nearer to real time.


2. Quantify Turnover in Past Performance
   When requesting that contracting firms provide past performance, the government should request an accounting of staff turnover in relation to the projects that the firms include in their proposals. Including a metric on the number of the firm’s staff members that contributed to the past performance and remain with the firm will give the government a much better perspective on the firm’s ability to achieve similar success. By making it a standard part of the procurement process, this will also cause firms to reward those staff members that achieve success for the government because they will become more critical to the firm’s ability to win new work. I believe that this would restore the balance between how the government and the contracting firms define success, reemphasizing delivery over revenue.
   
   This is probably a bit easier for the government to achieve than my first recommendation. I can’t think of much of a downside here except that it may somehow violate government acquisition regulations. But, given that the government often requests that firms include a retention strategy as part of their proposals, I’m willing to bet that this would be a reasonable option to implement.


3. Hire Independent Technical Advisors
   While I’m loathe to advise the government that it needs to spend more money, the Healthcare.gov roll-out demonstrates the high cost of failure. To promote the best opportunity for success, especially on large IT projects, the government could hire a small group of technical advisors who specialize in specific technology areas that apply to a given project. Rather than cull these advisors from the usual contracting firm suspects, I suggest that the advisors come from technology companies that would not have a direct interest in the procurement. They would form a kind of technology board of directors that would guide government managers in defining requirements and assist them in technical decision-making over the course of the project execution.
   
   Government managers could use this project technology board in any variety of ways, but I would suggest periodic engagement versus turning the positions into high-hour consulting gigs. I’ve found that technology executives are very willing to commit some modest number of hours to assist the government. For perhaps a day of time every quarter, the government could gain valuable insight into the viability of its approach on IT projects and an independent perspective on the performance of engaged contractors.
   
   In return, technology executives would gain some prestige as government advisors and insight into how the government procures technology solutions would prove valuable, especially for executives unfamiliar with the government space.

These suggestions do not represent an end-all. Change in the government is painful and slow, with overbearing acquisition regulations combining with inefficient agency processes to intimidate all but the most idealistic and driven change agents. But, the failed roll-out of Healthcare.gov should represent a key moment in Federal contracting in which firms should expect to be held more responsible for not just their execution, but also how they present past experience. I just doubt that it will.

As for CGI Federal, the government is now in the process of removing the firm from the Healthcare.gov integration effort, selecting another firm, Accenture, to replace it. HHS made this decision without competition, granting Accenture a sole-source contract for "expediency." Cue media back checks into Accenture's background. If you go back as far as the Washington Post did in researching CGI Federal's past as American Management Systems (AMS), you would find that Accenture was formerly known by the name Andersen Consulting, affiliated with Arthur Andersen. Take a look at Accenture's history yourself and let me know if you feel any better about the Healthcare.gov prospects.