By Eric Thomas
President Obama recently admitted that Americans are facing difficulties attempting to sign up for insurance coverage via the healthcare.gov Website. His disappointment has been echoed by both proponents and opponents of the underlying legislation. The Department of Health and Human Services (DHHS) explained that users “have had trouble creating accounts and logging in to the site, while others have received confusing error messages, or had to wait for slow page loads or forms that failed to respond in a timely fashion.”
Ever since these problems first surfaced after the go-live date of Oct. 1, industry insiders and technologists have proposed a litany of reasons that could have led to the current situation. Reasons included everything from too much focus on external design and not enough focus on integration; poor testing practices; inefficient government contracting laws; not using the best resources; and overreliance on antiquated system development methodologies. And while all of these may be true, there are other, lesser reported project management lessons that CIOs can learn from the unsuccessful rollout of HealthCare.Gov.
Here are four key takeaways:
1. Communicate the bad news early on. The project to develop HealthCare.Gov exceeded initial cost projections. And it was not just by a little bit, but perhaps by as much as 300 percent. Basic project management would flag this as a significant problem. However, the ultimate customers, the American people, were not informed. Proactively communicating overruns or other problems with the project may have damaged credibility and hurt politically in the short run, but it would have been better than what did transpire.
2. Acknowledge your risks and manage them. Some of the biggest risks with this implementation would involve schedule delays, cost overruns, privacy and security issues, and functionality. Mitigating those risks would have to be the key priority for such a highly visible rollout. But with as many as 15 contractors working on the development, risks could get lost in the vast network of contractor support. Hopefully, the contractors themselves are not responsible for reporting and managing risks since that would present a blatant conflict of interest. (While an outside management consultant did warn of problems with the site, these warnings were largely unheeded.) One of the site’s core problems was inadequate management of these risks, which subsequently spiraled out of control.
3. Beta can be your best friend. A beta site might not have been feasible for HealthCare.gov, but a minimally viable solution would have provided the environment needed for developers to test and improve the integration and the Website’s underlying technologies. Wherever possible, CIOs should take advantage of user willingness to freely test beta developments.
4. Know who is in charge. The Website was managed out of the Centers for Medicare and Medicaid Services (CMS), which is an agency under DHHS. There is an administrator for CMS and a secretary for DHHS. There is an Office of Information Services within CMS and a secretary for information technology at DHHS. But don’t forget the White House has a CTO of its own. The Office of Management and Budget, which is part of the Executive Office, has a CIO. And the Government Accountability Office, which is part of the legislative branch, has a director of information technology management. In this authority-dense environment, it is no wonder there could be a lack of clearly defined leadership.
Ultimately, there should be a project management office or, at the least, a single point of contact through which all issues about scope, risk, cost and requirements can be collated, communicated and managed. These persons should be independent from the development team and, if necessary, have the authority and access to escalate issues to the key stakeholders. Hopefully, these project management lessons can be employed for the benefit of your next big rollout.
