Website Development Lessons from the healthcare.gov Launch

healthcare.gov websiteRegardless of your opinion of the Affordable Care Act, it’s hard to avoid the view that the rollout of its website component, healthcare.gov, has been, umm, problematic. Perhaps even a train wreck. Of a really, really, big train. Carrying a lot of people.

I’ve read a number of articles about the usability and technical issues that have plagued the rollout of healthcare.gov. But I’d wager that underlying those issues were problems of project management.

Reading various analyses of the issue (links listed at the end of this post) brought back some not-so-fond memories of working on projects in technology start-up companies that were also poisoned, not by incompetence or lack of resources, but by deadlines that were determined by outside demands rather than realistic project specifications.

The phrase I’ve heard to describe this problem is “It takes a woman nine months to make a baby. You can’t make a baby in a month with nine women.”

In the projects I worked on, the outside demands were either market forces (we need to get this to market before our competitor!) or funding issues (at our burn rate, we need to launch by March or we’ll run out of money!). And those are real issues that can tank not just a project, but a company.

But good luck getting that baby to term in a month because the VP of Sales demands that you Make It So.

Another issue that caused problems with the healthcare.gov launch is “feature creep” (specifically, the requirement that users register before browsing was added “far along in the development process”). Ideally, the specifications for a project are set at the start, and you build to those specs. The only way that the specs change is in response to discoveries during development, e.g, you realize during testing that you need a different server configuration. But you don’t want to add or change the basic requirements once the project is underway.

The last stage of a web development project, prior to launch, is testing. The testing phase is the one that gets squeezed if project delays push up against a hard deadline. So you have the choice of launching something that hasn’t been fully tested, or pushing back the deadline.

links to articles

Here are some links to articles about various (non-political!) aspects of the healthcare.gov launch:

5 key questions await developers of healthcare.gov (From NBC News, a rundown of general project management and technical issues)

IT experts question architecture of Obamacare website (From Reuters, focused primarily on technical issues)

Launching HealthCare.gov (From the blog of Development Seed, the front end developer on healthcare.gov, written approximately 100 days prior to launch)

How We Build CMS-Free Websites (Also from the blog of Development Seed, giving some background on their development tools and philosophy)

Usability of Healthcare.gov — Performance Problems Trump Effective Design (from the blog of Intuitive Company, a Philadelphia company focused on user-centered design. They have a generally sanguine view of the user interface.)

A design critique of HealthCare.Gov (From the digital design department of the Washington Post, a generally critical view of the user interface)

Healthcare.Gov Fiasco Shows the Problems in Federal IT (from the blog Word of Pie, by a developer with experience dealing with Federal IT and procurement. He believes that the Federal IT procurement process is broken, dooming the project from the start.)

9 Things You Should Know Before Debating HealthCare.gov, From Someone Who Actually Launched a Successful Government Website (From Tech President, a good summary of the big-picture issues, and a refreshingly optimistic view of how to do things the right way.