Affordable Care Act Website Lessons
In the news, we’ve been hearing about the Affordable Care Act (Obamacare) and the website issues they’ve had during the go-live on October 1. As of today, the reported cost for planning, development, coding and roll-out of the website is at $394 million USD.
So what went wrong? It is too early to tell exactly, but the early evidence is leaning toward limited testing among other issues. It will be interesting to find out (if we ever do) what exactly went wrong.
What lessons can we learn?
First off, after viewing testimony to Congress today by the consulting companies who took on the project, there needs to be a very strong leader of the project. The buck stops with them. It doesn’t seem there were clear chains of command between the companies.
As with many government projects, the timeline for implementation was not realistic. From reports, coding was taking place right up to the time of go-live. This is nearly always fatal to a project. Time needed to be allotted in the plan to handle unit testing and end-to-end testing. There wasn’t a clear understanding of who was to do that testing according to testimony to Congress.
We are also learning that basic security precautions were not coded into the website. This has opened the door to potential data compromise that would have wide-reaching ramifications. It is still too early to tell if this will become a larger problem, but the hope is the security holes will be fixed before data loss can occur.
One of the main complaints of the site is the requirement to have people register completely (including a tremendous amount of Non-Public Information such as SSN, wages and so on) before they were able to “shop” on the site. The developers of the site didn’t take into consideration that visitors generally like to look around and get estimates before going through with registration. Because of the registration requirement, the registration module was overwhelmed and could not handle the traffic.
That leads into another issue. Capacity planning seems to have been shortsighted. The government’s own estimates prior to implementation were there would be millions of people signing up. The project leaders should have been able to plan capacity (servers and so forth) much better so the site slowdowns and other issues would not have been as severe.
This is just a start. As the implementation continues, and the “Surge” proposed by the President (of tech people) takes place, we will see and hear of other issues. Costs are sure to rise. This story is by far not over.
So what can we, as business people, take away from this?
- Project timelines must be realistic for the scope of the project.
- Adequate time MUST be in the plan for unit testing as well as end-to-end testing once major coding is completed.
- A clear delineation of process owners must be drawn up. Know who is doing design, coding, unit testing and final testing.
- Plan for adequate capacity.
- Follow industry standard coding methods when building sites that will deal with NPI (Non-Public Information) and PII (Personally Identifiable Information).
- Utilize outside testing firms to verify the security of your system. Companies such as Whitehat Security and Qualys are out there to make sure you are closing all of the holes possible.
- Plan your user interface wisely. Don’t make people go through lengthy registration processes until it is absolutely necessary. People are turned off by having to register to get basic information from the site.
- Test, Test, Test and then Test some more before going live.
Only time will tell how the government will work through the issues associated with the ACA website. One thing we do know is it will cost the taxpayers even more now to get working correctly.