The HealthCare.gov rollout: What should we learn?

The troubled launch of HealthCare.gov pains me – as someone who has great passion for wanting to make government IT more effective, this public spectacle once again casts federal IT in a very negative light. As a federal IT community we appear unempowered, and worse, incompetent.

My observations here are based solely on public information I have gleaned through the media and listening to the various congressional hearings. I was never close to the planning or development of the HealthCare.gov website and supporting back-end systems. In full disclosure, however, I did participate in one HealthCare.gov planning session a couple of years ago when I was Department of Homeland Security CIO. The session was to ensure various agencies (including DHS) identified the individuals to work with the Centers for Medicare and Medicaid Services on the required data-sharing to support the enrollment process.

A significant part of my 30-year career has been devoted to IT program management and oversight. For a system as complex as HealthCare.gov, best practice would have led to a plan that included: 

1) Completion and testing of all subsystems six months prior to public launch.

2) Three months of end-to-end functional integration testing.

3) Concurrent performance testing that would have simulated loads up to 10 times greater than expected (especially since it was difficult to model expected peak loads).

4) A subsequent three-month pilot phase in which selected groups of users were using the system to work off problems not caught in testing.

While I do not know for certain, I would expect that CMS had original development plans that were close to best practice. Yet some of the contractors involved have admitted that there were only two weeks of end-to-end integration testing prior to launch. That means the American public is serving as the integration testers of this system – not a situation anyone would ever plan for or want.

So what happened? There is pattern recognition for those of us who have been involved in many large IT programs. First, it is difficult to accurately plan the level of effort and time to develop new systems that are composed of complex and interdependent subsystems. Hence, there should have been schedule management reserve built in up-front, at least three months and perhaps as much as six months.

Second, given that different contractors were responsible for different subsystems, there needed to be a strong and competent program management office (PMO) that oversaw the program and the integration of the subsystems into a coherent, functional system. The evidence suggests that the PMO was not nearly as effective as required.

Third, the launch date of Oct. 1 was deemed immovable. As development schedules slipped, as integration challenges mounted, there were clearly compromises made so as not to delay the launch. I suspect little functionality could be deferred (the site must enable the full enrollment process), so what was compromised is good practice. It is simply bad practice to launch a complex system with very little end-to-end testing. There is no excuse for this, and given the complexity of systems CMS operates, there are clearly individuals in CMS who knew this launch would not go well because of inadequate testing.

Finally, there is the biggest failure, and the one that dooms many IT projects: The correct roles and authorities were not assigned to the business and the IT organizations. (In this case the business organization would have included leaders from CMS, HHS and possibly the White House).  

When I review an IT program, that role assignment and the authorities are one of the first things I look at to assess the health of that program. The evidence on the launch of HealthCare.gov shows clearly the balance was not correct. As reported by the media, a change in a requirement that disabled the ability for users to browse insurance policies without first enrolling was made just two weeks before launch. This was much too late -- requirements should have been locked down months before then. The business organization had the ability to make changes that led to bad program management practice.

In subsequent columns I plan to address a number of issues and recommendations regarding large IT program management. But for now, let's focus on how to address the proper partnership between the business and IT.

There must be a program governance model in place that recognizes the proper roles and authorities of the business organization and the IT organization for there to be success.  The business organization must be intimately involved in helping define requirements, making hard functionality trade-offs, and being a champion for the program with stakeholders both inside and outside the agency. The IT organization must establish a solid PMO with appropriate use of best practices to deliver large IT programs. And there needs to be a regular forum in which the business organization and IT organization executives work together to help the PMO make the tough decisions in running a program.

A fundamental tenet, however, is that sound program management practice must always be followed. There are no shortcuts to delivering large, complex IT programs. Having been intimately involved in dozens of such programs, I can state with absolute certainty that executing with anything less than solid program management practice is very high risk and leads to failures. The administration would be well served to incorporate the proper governance model for all large, complex IT programs.

One last point: The team of government personnel and contractors correcting HealthCare.gov must be working tremendously long hours and are under tremendous pressure. I thank them for their efforts.