Healthcare.gov web site launch leaves lessons for health of your IT career

While a lot of people are furious at the mess that was the healthcare.gov web site rollout, IT pros should use it as a learning experience for their own IT careers.

IT pros following the troubled launch of healthcare.gov can only feel grateful that they were looking at it purely clinically, and as “outside observers”—especially if they were reading some the criticism about the web site in national publications. The President was even quoted in international presses as he acknowledged the web site’s problems, saying "There's no sugarcoating it. The web site has been too slow. People have been getting stuck during the application process. And I think it's fair to say that nobody is more frustrated by that than I am." 

Nevertheless, if your career is IT, you look to learn from it.

The Washington Post published a detailed technical analysis of what went wrong. The conclusion was that there was a wide range of systems integration, web site performance, testing, usability, communications and “creeping enhancement” issues that were never adequately addressed. Collectively, these issues snowballed until the project spun out of control—but a call was made for the web site to “go live” anyway.

It made me reflect on an earlier moment in my career, when I was asked to assume the project manager position for a Wall Street online trading system project that was failing. The client had already sunk millions of dollars into the project. It had been told the project was “nearly ready,” but when I evaluated the project as a new manager taking over, I could see that the project wasn’t close to being ready.

I held a meeting with the client’s Executive Vice President and told him the situation. I can still remember him threatening to throw me and my lead managers (who were also with me) out the window! (His office was on the 46th floor.) Nevertheless, we all went back to our respective companies and presented the unvarnished facts—and we set the project back so it could be properly tested and prepared for launch. When it launched six months later, it worked—without a hitch. 

This lesson has stayed with me throughout my IT career—and it should have been operative for healthcare.gov. In other words, never let a highly visible project with so much at stake fail! First, this magnitude of failure is a career risk for someone (and he’s usually working in IT). Second, failure allows project detractors to thrive.

There are other “IT lessons” that this project also delivers. They include:

Testing and quality assurance

We preach testing and QA for systems, but let’s face it: when project timelines get tight, stuff can get “thrown over the wall” just to meet deadline. I’ve received new software releases from major technology vendors that included modules that weren’t even compiled, let alone tested! 

In the case of healthcare.gov, reports were already surfacing days and even weeks before the launch of the Website that it hadn’t been properly tested.

This testing should have occurred on several levels:

• End user experience (EUE) testing to ensure that the Website was easy to use (it proved not to be);
• Integration testing to ensure that 112 different systems and the efforts of 55 different vendors were all working together correctly (they weren’t); and
• Stress testing that would have ensured that the system was sufficiently robust to handle more than the 14.6 million unique user visits that the system experienced in its first ten days of operation (it couldn’t).

Vendor management

There were 55 different contractors for this project. When congressional hearings commenced, no one asserted a “lead role,” and it’s still unclear who ultimately was responsible for the project.

Some placed blame on government procurement practices that didn’t emphasize the key success factors needed to make an IT project like this work. Whatever the issues, a federation of 55 different contractors with no one clearly leading is too many participants to manage in a project with such heavy integration requirements. It’s also unclear what SLAs (service level agreements) were defined in vendor contracts, but clearly some SLAs should have addressed work product integration with the overall system.

Enhancement control

At some point, project managers have to freeze enhancements so projects can be fully tested and released. Apparently, there were late calls for enhancements just weeks before healthcare.gov went live. This is where the project manager needs to make the unpopular call of pushing the project back when he can’t guarantee the quality of the results.