How to Avoid a Launch Like Healthcare.gov

The headlines this week are all about the botched rollout of Healthcare.gov, the website for the Affordable Care Act (a.k.a. "Obamacare"). Being that website launches are a common event with our company, I cringe when I read about the unfolding disaster on display for the world to see (and criticize). Initially, the focus was the lead development partner and how they "failed". This obviously hits close to home, and I could sense the frustration and anger I'm sure was being felt by the development team. Was this really their fault, or is there more to the story? If you look past the politics and finger pointing, what emerges is a classic recipe for failure that any website development project can fall victim to. The problems with the website have little or nothing to do with the capabilities of the development firms hired for the project. What we're seeing now is a very common end result of bad planning, poor leadership and unrealistic expectations. The difference here is that it's all being played out on a national stage, under intense media scrutiny and with a chorus of politically motivated voices calling for blood. If you put all that aside, there are some valuable lessons here that anyone undertaking a development effort should pay attention to and a great example that illustrates why we do what we do at Diagram.

Make Sure You Have a Knowledgeable and Capable Project Leader

No project, no matter how big or small, is going to succeed without someone taking charge and leading the team to completion. Simply put, someone needs to be driving the ship. With the Healthcare.gov launch, the talking heads will point out that ultimately the buck stops with the President (I'm sure the POTUS never though his job description would include building a website). But in reality, someone with a thorough technical understanding of the entire project who is deeply involved with the various parties contributing to the end product and who is accountable for the end result is an essential element for success. In this case, several large contributors worked in tandem without a strong central leadership role coordinating their efforts. The government agency assigned to spearhead the project was not equipped with the knowledge or experience necessary to perform this function. Each contractor was narrowly focused on completing their particular piece, but no one with a high level view of the project was in place to make sure the various pieces actually fit together and worked properly. It was assumed that the highly qualified and well paid contractors would successfully complete their parts, and everything would nicely fall into place. Not so much. Each group working on the project really only has a firm grasp of their particular piece of the puzzle. How their piece is supposed to fit with all the other pieces isn't necessarily their problem. That's where strong project leadership should step in and provide the guidance to make sure the master plan has accounted for all the variables and intricacies that can (and did) derail a website.

Set Realistic Timeframes

Besides budget, the timeline is often the first victim of a poorly managed and improperly executed web development project. Unfortunately, many project stakeholders are unwilling to move the deadlines when things don't go as planned. I can understand pressure from bosses, fear of failure and other pressing influences that drive people to stick to a timeline at all costs, especially when your boss is the President. But the reality is, if the project details veer from the original path and new complexities and unforeseen complications arise, it is very likely that the new scope of work will no longer fit within your timeline. Adding more people and working more hours won't do much to help either and may, in fact, cause more delays (see Brooks's Law). The Healthcare.gov project was dealt numerous curveballs and a long list of problems, as you can expect from a project as vast and complicated as this. Unfortunately, the prevailing attitude seemed to be that the deadline was the deadline and the site had to launch no matter what. I'm guessing those decisions are being second guessed right about now. A few weeks of delays, while certainly not ideal, is a far better option than a failed launch.

Test, Test and Test Again

Testing… Everyone hates to do it, but you're doomed if you avoid it. In the scenario above, when the timelines start to shrink, time for testing is usually sacrificed. Clearly this was the case with Healthcare.gov. Testing occurred during the final weeks of the project when ideally it should have occurred during the final months. I've been involved with building websites for a very long time, and I can say with certainty that even the best developers and designers make mistakes and some things just don't work as you had planned. Unless you provide ample time and energy to testing every facet of the website, those bugs will find their way into production and the results can affect your brand and your legitimacy. But don't wait until the end of the project to begin testing. Test early, test often and when you think you're done, test again.

I'm sure Healthcare.gov will eventually get straightened out and working as planned. I also hope the government learned a few lessons about website development, although I doubt it. But at least this ongoing drama has provided a very good cautionary tale for anyone else embarking on a large scale web development project.

SOURCES AND ADDITIONAL READING:

1: Ars Technica, "The Seven Deadly Sins of Healthcare.gov."

2: Slate, "What Really Went Wrong With Healthcare.gov"

3: FedScoop, "Committee Demands Answers of Healthcare.gov from Contractors"