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.