5 Important Lessons from Healthcare.gov

p dir="ltr">As the recent rollout of the new Health Insurance Marketplace site has experienced a few hiccups, the public has gotten a glimpse of what can happen when things go very wrong on a newly launched website.  And while the Obamacare site is the most public example, this kind of thing actually happens all the time.

Information is still trickling out as to what went wrong in Healthcare.gov’s development process, but there are already lessons to be learned.  At NPG, we have some rules and processes in place to make sure your site launch is as smooth as possible.  Here are a few steps you can take to make your deployment a success:

1) Destroy silos

Healthcare.gov is probably one of the more complicated web systems ever built.  When a single person applies for insurance, the site queries over a dozen government departments and insurance companies in order to verify personal information and supply a quote.  The contract to build the site was separated between front-end developers and back-end developers with less thought given to coordination between the two.

Most websites will have to interface with other systems either within your organization or with third parties.  At the very minimum, sites are usually deployed to a server that is not owned by your web developers.  While IT departments have legitimate security concerns, it is important to make sure that your development team does not have to build anything blindly.

2) Make sure you know who is accountable

Besides avoiding information silos, you need to make sure there is a single point person.  Only recently, the government appointed Jeffrey Zients to get Healthcare.gov working. Don’t wait until it’s too late!

On our end, the project manager is responsible for making sure that the project meets all requirements.  You will need to make sure that your organization also has a single person that can confirm requirements, gather feedback and share concerns.

3) Test in Realistic Conditions and Plan for Success

Much has been made of the fact that Healthcare.gov went down in the face of millions of enthusiastic visitors.  While all sites undergo load testing as part of regular Quality Assurance, make sure you have realistic expectations as to how popular your site might be.  We can recommend the appropriate hosting environment and make sure that your site will scale.

The corollary here is that sometimes the client can be the best tester.  You know your audience and business best.  A test is only as good as its inputs.  A site that is processing real data and displaying actual content can be tested more accurate than a site full of Lorem Ipsum.

4) Don’t Change Requirements Late in the Game

Enough said.

5) Avoid Artificial Deadlines

The last two lessons are intimately related.

Without descending into the politics, it’s clear that the government got off to a late start in setting final requirements and building Healthcare.gov, but was unwilling or unable to adjust its final due date accordingly.

Sometimes you have a hard deadline and that’s ok.  But that means the entire development process needs to stay on schedule.  Delays in finalizing requirements or selecting designs without changes to the deadline require a compressed development schedule.  Oftentimes, this means that the time allotted for testing before deployment shrinks.

If you need to make significant changes or fall behind schedule, it’s worth considering whether your deadline is real or artificial.  It is better to launch a fully tested site 10 days (or even 25 days) late than to deploy a barely finished site and hope for the best.  The site will be finished around the same time, but the stress and potential opportunities for embarrassing bugs will be greatly reduced.