A Shaky Start for HealthCare.Gov
A Shaky Start for HealthCare.Gov
Original Query
A Shaky Start for HealthCare.Gov - Analysis of project implementation, risk factors, management problems, and lessons learned from the troubled launch of the Affordable Care Act's health insurance marketplace website.
Why Was the HealthCare.gov Project So Important?
The Affordable Care Act (ACA), signed into law on March 23, 2010, by President Barack Obama changed health care for all Americans from the date enacted. Hamel, Blumenthal, Abrams, & Nuzum (2015) point out that the two principal goals of the ACA are the expansion of health insurance and a new health care delivery system with the main access points for customers is the website HealthCare.gov. They go on to discuss during the first five years of the ACA the estimated number of uninsured who have signed up for health insurance including young adults had become eligible to join their parents' policies, is estimated to be at least 16.4 million. Of all the users signed up 87% received a government subsidy.
The government health insurance subsidies were critical for signing communities with no insurance coverage. They were Hispanics, Blacks, young adults, and people with incomes that were low. The ACA which includes the HealthCare.gov was important because finally, after many years the website enables people without health insurance to sign up, compare prices, insurance deductibles and qualify for government subsidies.
Key Risk Factors in the Project
Management Risks
The HealthCare.gov website had project risk factors. One was the fact that no owner or leader was managing the project to build the new site as pointed out by Laudon & Laudon (2015). Without proper management, projects can take longer to complete and usually run into cost overruns. Howles (2014) discuss how a lack of management decision authority in the project led to delays in making policy decisions that impacted the requirements and resulted in a reduction in time to deliver the project on time with a fixed completion time of October 1st, 2013.
They go on to discuss how the CTO of the White House, the CIO of the Office Management and Budget, and the CIO of the Health and Human Services who had oversight responsibility for the website did not attend the meetings about the project status. Based on roles these people had in the government they had accountability but choose not to participate in the meetings where milestones were planned and laid out. No involvement or interest in resolving policy or issues at project status meetings, by these people, put the elevated risk on the project that would be resolved quicker if the government officials engaged themselves in status meetings throughout the project lifecycle.
On October 25th, 2014 QSSI took over HealthCare.Gov as the general contractor as discussed by Cundiff et al. (2014). They focused on getting contractors working with the speed and urgency of a high-tech company instead of normal government operations. Daily progress reports were put in place and with the management in place at least fifty bug fixes were getting resolved each week. With this new management in place, they were able to stabilize the site to handle the traffic now coming to HealthCare.gov
The large size of the project was another risk factor. Cundiff et al. (2014) identified at the start of the project, there were fifty-five contracted agencies and the HealthCare.gov website was to link to over one hundred different computer systems across the country with these data connections delivered via a data hub on the back end of the website. HealthCare.gov is a large project to rollout in one release and went live with the so many features included in the entire site. A better approach to lowering the risk is to stagger the application systems feature rollout and break the roll out the brining system data connections online into smaller batches.
Technology Risks
There were some technology risks in the kind of software chosen for the project. Laudon & Laudon (2015) point out that the use of the MarkLogic database software was difficult for team members to use because it handles differently than other database software. The hardware and software technology sizing was a risk that could have been avoided if the team performed load testing on the production hardware before the launch. Time had run out, and there was no time to handle this.
Another option to lower the software and hardware risk is to allow the systems to scale with the traffic volume horizontally. If moving this application to the cloud could not be accomplished due to security issues, a private cloud or virtual machines could be used to scale horizontally when traffic volumes increased. Scaling automatically could have lowered the risk of outage with the volume of people access the site in the first few days of operation.
Classification of Problems Encountered
Management Problems
One problem encountered was that the federal contracting process awarded the contract for HealthCare.gov, but the government had no management leader to oversee and own large HealthCare.gov software development project. Jain, Powers, & Sanghavi (2015) point out that the software development of HealthCare.gov included 55 sub-contractors that were responsible for building the website but during the process, there were very few opportunities for collaboration and no one government representative or project office overseeing these teams. No one person owned the project and sub-contractors were spread out in different areas. There were no daily status updates or tracking a timeline occurred by a project owner so the project did not go according to plan. Once the government realized this major management problem, they brought in a private sector group of contractors and operated outside the federal contracting process and had the website issues resolved in six weeks.
Laudon & Laudon (2015) point out that in mid-July 2014, Government Accountability Office, the agency the provides investigative services and auditing evaluated the HealthCare.gov project and found that the project was developed without effective organization and planning or oversight practices.
Organization Problems
No one government employee was held accountable for the HealthCare.gov website during the project was another problem. With no one in charge, this caused issues with the project plan. It was not solid but had scope creep. Scope creep, described as constantly changing project requirements, and timelines continued to change during the project. The project plan timeline continued to shift regularly and time allocated to perform project testing was down two weeks instead of two months as pointed out by Keil, Smith, Iacovou, & Thompson (2014). The shortened timeline for testing was forced by a hard deadline of October 1st, 2013. This date the government had set in stone and would not delay the delivery of the project.
A couple of weeks before the release of the HealthCare.gov, it was decided that the requirement for users to create a new account before they could shop for insurance plans in the marketplace on the website. That meant that two weeks before go live a design change occurred. The poor performance issues experience on the day the website launch could have been avoided if changes to the application code were not done such a short time before the release of the system to the general public.
Problems that Laudon & Laudon (2015) discussed how the Centers for Medicare and Medicaid Services (CMS) helped the team coordinate development effort. CMS sub-contracted much of the work to other companies. CMS set deadlines for the contractors, but they did not attend meetings they were supposed to define the requirements for HealthCare.gov website, and many contractors that worked on different parts of the system did not communicate with each other. They go on to describe that the CGI Group (CGI) voiced their opinion that with all the new scope creep that occurred during the project that is delivering the fully function website HealthCare.gov was not realistic to complete by the October 1st 2013 deadline the government insisted they would not change.
Technology Problems
Keil, Smith, Iacovou, & Thompson (2014) describe the issues with HealthCare.gov at launch was that the project implementation had no leadership or a clear direction and the requirements continued to change up until shortly before the system went live. So requirements were changed two weeks before the go-live date. Along with this, the reduction in test schedule time to weeks instead of months, so this left little or no time to identify and fix integration problems. They go on to describe that complex IT projects do not fail overnight but fail every day until project owners can fix blockers to project issues and move the project forward without loosing to much time.
On the day of the launch of the website HealthCare.gov, there were many technical problems. Many of the technical problems as described by Laudon & Laudon (2015) were related to project oversight. These problems varied from application pull downs not having correct information, to time outs on the website do to slow application performance, under specced infrastructure hardware and even firewall issues. Another problem that caused technical problems was the minimalistic approach to testing the system. Howles (2014) identified that much of the functional testing was done on developer workstations rather than on the live production system and no integration testing conducted on the front or back end of the system. They also pointed out that the load tests did not scale up to the estimated number of users and therefore was not a comparable load test to the expected number visitors when the site went live.
Another technical issue that was a worry were security issues on the website. Petrie (2014) discuss that after the site had performance issues, one of the contractors in place to fix performance issues discussed with one of the contractors in charge of software security what penetration testing had been executed against the HealthCare.gov site. The software security contractor responded with the fact that penetration testing was not their role, but they were a doing regular risk assessments. A risk assessment in the mind of the software security contractor meant to be sure that the security obligations as spelled out in the contract to build HealthCare.gove were met and not anything that was not defined or spelled out in the development contract.
Economic, Political, and Social Impact
There were economic, political and social implications to of the Healthcare.gov project. The economic consequences as described by Laudon & Laudon (2015) discussed a project that started out costing $93.7 million dollars and ended up costing over $500 million by the time the stabilization of the site was complete. That economic impact was a cost overrun of more than five times the original estimated cost that the tax payers had to pay due to poor project management and oversight by the Barack Obama at the highest level.
The political impact of not delivering would bring unrest between the Democratic and Republican parties. It is assumed that the political pressure of the failed launch of HealthCare.gov caused Kathleen Sibelius to resign from her post as Secretary of Health and Human Service in April of 2014 as Laudon and Laudon (2015) pointed out.
The Social impact for the site would have been the frustration by the public trying to use the site while trying to sign up for healthcare plans. Cundiff et al. (2014) point out that when the site launch there were 250,000 connections and 8.1 million customers over a four day period. It was estimated that one percent of customers were able to complete entering personal information and enrolling in a health insurance plan. The legislation passed but, to be successful the rollout of the website was a key component of the legislation. Without the site in place, it battered the public support for the program and the site.
Preventative Steps for Better Outcomes
Steps could have been adopted to avoid an adverse outcome to this larger project. Two stepe that should have been taken are a leader to manage and own the project implementation and the use of an iterative development methodology such as Agile development. If the team did not want to use Agile development, the project managers could have be running something like Microsoft Project Team Planner instead of traditional project management tools. The Microsoft Project Team Planner would allow all projects by each separate contract company to be tracked as one and identify issues and enable quick resolution as one large project instead of many small Microsoft Projects maintained by each team.
With many contracting companies involved daily, management and statuses would need to be done to keep up with all the work, issues or blockers that need immediate attention. Putting this in place would stop wasting time and money to complete the project. Stopping random the government policy changes that affect finishing the project deliverables on time and putting a government leader in place that owned the development are steps that should have been taken to prevent an adverse outcome to the project. If a government project leader or executive was in charge of the site pushed back on the President and policy makers when they wanted to make changes the project may not have had an adverse outcome. A government project leader or executive would make them aware that if they change a policy or requirement with the project in progress, that the timeline will have to be extended or features will have to be dropped and completed after the launch day of October 1st, 2013.
References
Healthcare.gov: Opportunity out of disaster Cundiff, J., McCallum, T., Rich, A., Truax, M., Ward, T., & Havelka, D. (2014). Journal article examining the Healthcare.gov implementation failure and opportunities for learning from the disaster. Published in Journal of Information Systems Education, 25(4), 289-293.
What can we learn from HealthCare.gov? Howles, T. (2014). Analysis of lessons learned from the Healthcare.gov project failure, focusing on software quality and testing issues. Published in Software Quality Professional, 16(2), 27-34.
Big plans, poor execution: The importance of governmental managerial innovation to health care reform Jain, Sachin H., M.D., M.B.A., Powers, Brian W., A.B., & Sanghavi, Darshak., M.D. (2015). Discussion of management failures in the Healthcare.gov project and the importance of governmental innovation. Journal of General Internal Medicine, 30(4), 395-397. doi:http://dx.doi.org.ezproxy1.apus.edu/10.1007/s11606-014-3083-7
The pitfalls of project status reporting Keil, M., Smith, H. J., Iacovou, C. L., & Thompson, R. L. (2014). Examination of project status reporting failures and their impact on project outcomes, with Healthcare.gov as a case study. MIT Sloan Management Review, 55(3), 57-64.
Management Information Systems: Managing the Digital Firm, 14th Edition Laudon, K. C., Laudon, J. P. (2015). Comprehensive textbook covering management information systems with case studies including the Healthcare.gov implementation. Pearson Education.
The failure of HealthCare.gov exposes silicon valley secrets Petrie, C. (2014). Analysis of the Healthcare.gov failure from a Silicon Valley technology perspective, examining security and development practices. IEEE Internet Computing, 18(6), 85-86. doi:10.1109/MIC.2014.121