An Outsider’s Opinion – Lessons Learned from the Healtcare.gov Roll-Out

Ian Nerney

By: Ian Nerney – Bayshore Solutions Project Manager

By now, you’ve probably heard about the infamous Healthcare.gov roll-out. This highly publicized, highly political website launch has faced its fair share of scrutiny over the last two-and-a-half months. As a project manager, the whole situation intrigues me. How did the website launch become such an issue? What went wrong in the production process? Better yet, what can we, in the industry, learn from this situation?

These are all questions I’ve been asking to myself over the last few months. However, to answer these questions, let’s first discuss the basic purpose for the website.

If you’re not familiar, Healthcare.gov is effectively a health insurance marketplace platform, creating ‘exchanges’ where individuals can compare prices on health insurance plans in their state, begin the enrollment process for their selected plan, and simultaneously find out if they qualify for government subsidies under the provisions of the Affordable Care Act. It was a large, complicated website design and development project for those involved, and is intended to act as the key management and operational unit for the program. The website was chartered, and is managed by the U.S. Department of Health and Human Services.

The concept, at its core, is simple – connect users with health insurance providers. However, to make this happen a complex system of data feeds and integrations would be required to bring forth information from various providers. Additionally, this data from various sources would need to work together seamlessly, and in near real-time. Not so simple now, is it?

So what went wrong? Well, at this point we can only speculate – at least until the Department of Health and Human Services releases the results of their official internal inquiry, currently underway. However, through secondary sources we’ve learned quite a bit about what went wrong, and we can begin to make some generalizations:

1. The rules and regulations for the Affordable Care Act were being modified until the summer of 2013, likely changing the requirements for the website. By not having a firm definition of quality, this would increase complexity and risk, decreasing the likelihood of project success.
2. On the first day of operations, only 1% of interested people were able to enroll on the website within the first week of operation. This implies that the site was not ready and fully tested for the October 1^st launch and that it was a work-in-progress until the very end.
3. After two months, and over code 400 deployments, the site went from working for 1% of users to 80% of users. This is significant progress, but shows that further testing and code deployments will be required to reach acceptable levels.

With these generalizations in mind, how can we, as industry professionals, learn from this? After reviewing the project, I believe there are four essential principles of IT project management which could have been reinforced to help alleviate the challenges faced at launch.

1. It’s important to have well-defined and realistic requirements. This is a crucial component of project planning, and it is the only way that quality can be measured. Without well-defined and realistic requirements, one could not expect to launch a site successfully.




2. There should be a plan in place for new discoveries and added complexity. In every website project, there are new discoveries which add unexpected challenges for the delivery team. With this project, in particular, the changing rules of the Affordable Care Act likely increased complexity and risk. To mitigate this risk, it may have been recommended that the project team adopt agile project management methodologies to produce small functional pieces which could be tested individually. This may have helped in the final product testing, and may have brought attention to other risks earlier in the process.




3. Hard deadlines negatively impact quality. Hard deadlines add risk to a project. Depending on the length of time allotted for project execution, planned project activities may need to be cut from the project, or additional resources may need to be added.
   




4. Testing is key. In order to ensure a project deliverable is working properly and is built to the required specifications, an in-depth unit testing of functional components would be required prior to launch. Unit testing should be an iterative process of reviews and revisions, each revision adding integrity and stability to the individual component, thus improving the system as a whole.

It is important for both clients and interactive agencies to change their mindset when it comes to projects. We can’t think of projects as a single end product, but rather a system of individual products, all working together for a common purpose. This line of thinking is the core principle of systems theory, and is the driving force behind agile project management methodologies.

By thinking in terms of individual functions, and understanding how the individual functions influence the overall system, the project delivery team may have been able to address the challenges and risks differently to create a better end product.

We, at Bayshore Solutions, believe that through effective planning, executing, monitoring, and controlling we can produce high quality results for our clients. To find out more about how we may be able to help you with your website design, development, or marketing efforts, please contact us.

Ian Nerney is a Project Manager at Bayshore Solutions—a Web Design, Web Development, and Digital Marketing Company.