Lessons of the Healthcare.gov Fiasco
Compared to other high-profile, complex federal IT programs, the ACA healthcare exchange program may have racked up the most program missteps for leadership and management in today’s IT world. On the other hand, other major government consolidation Web sites, such as USAJOBS and USAspending, have had significant IT problems as well. Revelations from key IT sources illustrate how immense the technology architecture and design problems are: missing or bad data, duplicate records, lack of audit controls, insufficient testing, and inadequate Cybersecurity controls, to name a few.
According to Aneesh Chopra, the first US Chief Technology Officer, the site’s problems were due to heavy traffic. It was built for 60,000 concurrent users – an estimate based on the Medicare.gov site of 30,000 daily users. However, Healthcare.gov had to support one million simultaneous users out of the gate. Also, the former CTO points to a minor Private Cloud scalability issue and a few additional IT missteps.
And yet, many insurance and technology leaders, analysts, Web developers, and contractors have pointed out serious IT methodology, architecture design and security flaws with the Healthcare.gov Web site as long ago as early 2012. These central IT challenges focus on leadership, management, architecture, cost management, IT workforce issues, and stakeholder decisions and roles.
This IT program appears to have fallen apart due to a number of requirement changes within two weeks of product launch from the administration. Such last minute changes introduce substantial risks into any IT project. All critical production systems should ideally have hard lead times and freeze dates, in conjunction with an iterative, Agile methodology for such changes to be successful. For example, the IRS has a similar IT playbook for new tax laws every year as many commercial firms do.
How to Fix Healthcare.gov
The number of critical technology areas that have been failing and the risk of skipping full operational and Cybersecurity testing and review place this application at high risk. The exchange portal needs an IT rescue or reset, which would involve taking the site down for application overhaul.
It may require as many as 5 million lines of software code to be ripped out and replaced to avoid inaccurate enrollment data and improper payments for services, mitigating further costly recovery. It should also have a full architecture review and be retested for data quality with key stakeholders, security for accessing other federal databases, as well as security for citizen privacy and data protection from hackers for identity fraud and misuse.
Key IT takeaways on this effort for any organization, federal or private, include:
- Executive teams should be flexible on critical product rollout dates and execute strong leadership using governance for accountability and transparency over requirement changes and risks to avoid program chaos on cost, schedule, Cybersecurity, quality, and usability.
- Executive leadership must have common product communication messaging on the purpose and value to all levels of the organization, stakeholders, and customers for accepting the product with confidence and trust.
- EA teams should have crafted an Agile Enterprise Architecture using a Cloud roadmap for driving the business needs today, as well as future requirements for improving customer satisfaction and usability.
- Executive and IT leadership decisions to insource complex integration architecture must be evaluated with the right team level of skill mix, training and resources, and leadership must be willing to outsource resources for any skill gaps.
- Procurement teams should use trusted partnerships with core domain, Agile Architecture, and project management (PM) skills as well as corporate or government-wide multiple award contracts with task orders for critical skills by best of breed contractors with key domain experience for Agile software development.
- Agile IT PM teams should have a standard or tailored software development lifecycle including a prototype phase for proof of concept with field ops for network stress on the architecture and security testing using incremental releases for production.
- IT PM teams should have leveraged key stakeholder sign-offs, domain tailored best practices, customers/users/advocacy testing groups, or other testing offerings to validate a new product.
Using a Web-based portal solution for a healthcare gateway to existing federal agencies’ databases and insurance interfaces for data sets with unpredictable scalability requirements are common IT challenges in today’s market that newer technologies, in particular, Cloud Computing, can address. On Healthcare.gov, the key executive strategy teams lacked the technical skills and the proper executive governance framework for oversight on the program’s execution effort. A delivery mandate, regardless of the end state of the product and “deliver as is” wording, puts the citizens or other users in a dysfunctional IT service environment, which creates lack of trust and confidence in the healthcare portal going forward.
If we compared this project rollout with any large private sector organization rollout, it would have been shut down immediately to mitigate the unknown costs and risks, the damage to the brand and reputation of the organization, and the leaders who are accountable would have taken appropriate management actions. In fact, it should not have led to a rollout date using a “big bang” deployment in the first place.
The Administration’s 2012 OMB policy dictates the use of Agile software using incremental releases to avoid the long delays for customer phase-in for smaller deployments (30 to 180 days), and early use of features and benefits to reduce risk from poor requirements, untested technology, software failures, and cost overruns. However, by all accounts, Healthcare.gov was executed as a waterfall project, an approach that almost always leads to failure – either by insufficiently delivering on requirements or by providing inadequate focus on quality. And sure enough, these are just the problems that Healthcare.gov faced.
Why, then, did the government and its contractors not follow a best practice Agile approach? Fundamentally, Agile requires a rethink of the organizational aspects of planning, delivering, testing, and managing any IT project. The entire effort must be tackled iteratively. Stakeholders should be involved at every step. Testing must take place in every iteration, in order to lessen the testing burden as the initiative approaches delivery.
For larger initiatives like Healthcare.gov, the architecture must be Agile as well – both the software architecture as well as the broader Enterprise Architecture. We must entirely rethink how we go about software delivery to meet the IT challenges of the 21st century. There is simply no excuse for high risk waterfall initiatives any more, at the federal government or anywhere else.
Guest Author: Steve Hawald, Executive Partner/Analyst
Prior to founding HAWALD ADVISORY, LLC in 2013, Mr. Hawald was a former Gartner global IT research analyst, US Department of Education / SFA CIO, and United HealthCare HMO Divisional CIO. He was named to Hitachi’s Federal Data Systems advisory board in early 2010, and was appointed to Georgetown University’s CCPE adjunct faculty for graduate IT certificate programs in 2009. He teaches part-time on weekends at the DC campus with his advisory engagements. He currently attends Virginia Tech University for STS PhD studies in risk challenges and management.