Healthcare // Leadership
Commentary
12/4/2013
08:06 AM
David F Carr
David F Carr
Commentary
Connect Directly
LinkedIn
Google+
Twitter
RSS
E-Mail
50%
50%

How Would You Fix HealthCare.gov?

The Obamacare website launch was an embarrassment. Whether it's truly "fixed" is questionable. What actions would you take, IT pros, and what lessons have you learned?

The HealthCare.gov website, the IT centerpiece for implementing Obamacare, is said to be "fixed" now -- although there are still plenty of reports of site access problems and deeper glitches in the software.

Ever since the glitch-ridden launch of the site on October 1, IT experts of all stripes have been weighing in with their thoughts on what went wrong and why. InformationWeek last week conducted a series of interviews with experts in which we asked for a more prescriptive analysis: How do you recover from an IT disaster on the scale of HealthCare.gov?

I recap some of the common themes (and differences of opinion) below, but we'd also like your point of view. Have you ever been involved in a technology turnaround on a big, important project that failed at launch? Did you see that initial failure coming? What are the most successful strategies you've seen for reorganizing for success?

It's hard not to revert to the "blame game" -- pointing out what should have been done in the first place but wasn't -- and there's plenty more to say about that. But put yourself in the shoes of Jeffrey Zients, the man drafted to get the HealthCare.gov project on track. Would you have deployed additional manpower in a "tech surge?" Would you have shut the site down while making repairs? Would you have outsourced more (or fewer) functions? And when you report back to President Obama, which specific recommendations would you make about federal government procurement reform or IT project management strategies? How would you make those changes stick, so that the next president, Republican or Democrat, will be able to make big e-government promises and keep them?

[Read our complete coverage of the HealthCare.gov launch here.]

This exercise shouldn't be about what you think of the Affordable Care Act, a.k.a. Obamacare. Although the two issues have become intertwined, the performance of the website and the wisdom of the law are two different things.

Whether you're cheering for the success or demise of Obamacare, the facts are the facts, and the fact is this technology implementation undercut the policy implementation. I think the president and his top advisers made far too many assumptions about how easy it would be to launch a consumer-friendly insurance shopping website. They failed to comprehend how much bigger a job it is than fielding, say, a campaign website.

Martin Abbott and Michael Fisher, a couple of scalability consultants and authors we interviewed, said the government's mistakes weren't so different from the ones they've seen many private companies make when they misjudge the needed scalability and capacity of their Web systems. The one big difference they see is the partisan environment surrounding the project, where those trying to salvage HealthCare.gov and the programs it represents are competing for attention with those who want them to fail.

Here are a few key questions surrounding the HealthCare.gov failure:

Should it have been shut down?
One of the things that didn't happen but should have, according to one camp, was to shut down the website while it was being fixed, on the premise that it was launched prematurely and clearly wasn't ready. We've heard this line of thinking from computer security experts, both in interviews and Congressional testimony. The overall performance of the website doesn't inspire confidence in its security, and there's also evidence that warnings of security flaws were ignored during the site's construction.

The implication is that the Obama administration failed to shut down the site for "political reasons," because it would have meant admitting defeat and delaying implementation of the law.

Richard Spires, a former Department of Homeland Security CIO, said he would have recommended shutting down the site for repairs -- politics aside. "It takes a lot of energy to run the site," Spires said, and that energy needed to be diverted into fixing functionality and testing performance.

Abbott and Fisher disagree, saying the best way to fix an underperforming website is to make incremental changes and test them against real-world traffic, not against simulated load tests. Even security problems are better solved with a methodical approach rather than a panicked shutdown, they said.

Also, one of the original sins of the Healthcare.gov implementers was that they sent it live in a big bang, trying to bring the site up to full capacity in one day rather than having some sort of beta period or soft launch to gradually build capacity and test functionality. If the site were taken offline and relaunched, that approach would amount to a second big bang -- and, likely, big problems, Abbott and Fisher said.

Bryce Williams, the founder of Extend Health and now managing director of exchanges for Towers Watson, agreed that no going concern -- inside government or outside -- would willingly shut down its primary website. A business would be even more likely to keep an underperforming site operating while working to improve it.

What would you do? Shut it down, or not? Why?

Is this a job for government IT? 
Former Air Force Col. Mark Douglas, who as a military IT leader oversaw some technology turnarounds, acknowledged the limits of the government's capability to build complex systems on its own. "The US government is not the leader in commercial IT, nor should it be," he said. Government employees must focus on the inherently governmental aspects of a program, creating an efficient division of labor with private industry partners.

On the other hand, one of the villains in this story is the government's process for procuring IT services. David Blumenthal, a former director of the Office of the National Coordinator for Health IT, argues that managers most involved in an IT project's requirements often are kept at arm's length from the people who select contractors to deliver on those requirements, making for unnecessary dysfunction.

Extend Health's Williams suggested another way the government could partner with private industry, by letting private insurance brokers (such as his) handle more of the consumer enrollments. Under that scenario, the government would focus on services that only it can provide, like providing an online determination of eligibility for federal subsidies, while private firms would be responsible for providing "a spectacular user experience," something he doesn't see as a government core competency.

What parts would you outsource? What would you keep in government hands? And if services are to be outsourced, how must the contracting process change?

Does a "tech surge" make sense?
Drawing an analogy from military operations in Iraq, the Obama administration decided to address HealthCare.gov’s problems with a "tech surge" of additional manpower, effort, and oversight. The experts we interviewed were ambivalent about the value of such a surge, saying that it's difficult for new people, no matter how talented, to come up to speed on a mature IT project and figure out what needs to be done to fix it. On the other hand, the existing team members may know what needs to be done but aren't empowered to do it.

"On mega, custom-coded IT implementations that trip before the finish line, many organizations want to throw money at the problem in the form of outsider IT SWAT teams. Keep your money," Col. Douglas advised, "unless your program team is literally incapable of fixing the problems." He added that it's "extremely difficult, expensive, and time-consuming to bring in new people to work on custom code."

Abbott and Fisher said project leaders could put additional manpower to good use as long as they focus it on identifying and correcting problems -- the hundreds of bugs the developers have been fixing over the past couple of months.

What do you say? Surge or no surge? Keep the project team or throw the bums out?

Those are some of our key questions. We'd like your answers. Also, what are the questions we forgot to ask?

Follow David F. Carr on Twitter @davidfcarr or Google+. He is the author of Social Collaboration For Dummies (October 2013).

Though the online exchange of medical records is central to the government's Meaningful Use program, the effort to make such transactions routine has just begun. Also in the Barriers to Health Information Exchange issue of InformationWeek Healthcare: why cloud startups favor Direct Protocol as a simpler alternative to centralized HIEs. (Free registration required.)

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Page 1 / 4   >   >>
Jen Bosavage
50%
50%
Jen Bosavage,
User Rank: Apprentice
12/4/2013 | 8:32:34 AM
Nothing to commend
It is a crime that the contractor is getting paid to fix the mistakes it made in the first place. In addition, building a site with virtually no security is ridiculous. Who does that? And the contractors used should have known better. Some of the IT players are not small names. The management from the HHS team was lacking as well. There is little that is good about the site.

What would I do? Take it off grid. Tell the contractor(s) they face a lawsuit if this is not cleaned up in 6 months. Extend the ACA deadline. Appoint someone new to oversee the project from the administrations inner circle, who has a tech advisor. Within 3 months, limited rollout, say within a geographic region. Grow as you go.

 
Laurianne
0%
100%
Laurianne,
User Rank: Author
12/4/2013 | 9:45:16 AM
Bidding system
I would also welcome your thoughts, readers, on whether this project could be the one to spur change related to the contractor bidding system the agencies use to do these projects. That lowest cost bidder system clearly played a role here -- a major one -- but will this episode give government IT leaders the ammo they need to change this situation? 
RobPreston
100%
0%
RobPreston,
User Rank: Author
12/4/2013 | 10:07:25 AM
Re: Nothing to commend
We've been told that the "frontend" of the site is working just fine now, but that the pesky "backend" may need some more work. That backend is where the rubber meets the road--it's where citizens actually get the coverage they signed up for rather than just think they have coverage based on a pleasant user experience. The fact that the administration isn't releasing stats in that area is telling, in my view. If the backend is not fixed -- if people thinking they have policies file claims and then nothing happens -- then this initial disaster will get far worse. Let's hope this "backend" is getting the attention and expertise it requires.   
Jen Bosavage
100%
0%
Jen Bosavage,
User Rank: Apprentice
12/4/2013 | 10:15:13 AM
Re: Nothing to commend
Absolutely, Rob. It is silly to say the front end is "good to go." The back end is what propels the entire thing! And if the public can't be sure  social security numbers are being handled securely -- that's a huge failing.

@Laurianne, I am not sure having the lowest bid is the problem here. Really, you can't make this work for $500 million? If the gov't had spend $1 million, then I'd concede the point. But $500 million was not a bargain basement price tag. We deserve far better quality for that amount of money.
Steve Naidamast
50%
50%
Steve Naidamast,
User Rank: Apprentice
12/4/2013 | 12:29:51 PM
Fix HealthCare.gov with a new site that is highly compartmentalized...
One of the serious problems with the HealtCare.gov website was the fact that it was outsourced in the first place, which then placed a $634 million price tag on the effort.  Who ever heard of a web-site costing that much no matter what it was intended to do?

In any event, outsourcing is one of the most serious issues the US government has had since Reagan (Yes, he's the initial culprit in a lot of this.) and in this case I would striongly suggest the reverse and bring the entire work back in-house and redeisgn a new and more efficient solution whileletting the outsourcers fix the issues with the current site.

This is a double-pronged effort but I don't believe there is much of an alternative if you want to keep the original site running while a new effort is inititiated.

From all of the technical analysis I have read so far, except for the front-end the entrire site is a complete mess, which I don;t quite understand.  If a state was going to opt out of the endeavor than it was their responsibility provide an alternative for whichthe site would have transferred users to for such states.  If participating in the effort than a single, fujnctional solution by the government should have been developed using the requirements of both states and insurance companies.

By modularizing by state and insurance companies, indivdiual web-sites could have been developed, which would have sat beneath the current interface, which should have been used simply as a portal to these individual sites.  So instead of simply transferring a user to a state site in which a state had opted out of the program, users in participating states would have been directed to subsites all with their own individual databases, all of which could be combed by an administration facility that could accrue summary\detail results for analysis.

Compartmentalization of software development has fallen into disuse with the hype over re-usability, which I imagine is one of the techniques that was used in the development of the current site.  However, re-usability has been proven over the years to be nothing more than hype except when implemented under very strict and limited circumstances.  And I have seen in my own development efforts how it has turned projects into complete messes as everyone is trying to make everything "generic".

Having upwards of 6000 outsourced technicians on such an endeavor could never have defined usable re-usable components while making a mess of compartmentalization.   You sijmply cannot control the outcome of such a massive project and recent analysis has found of such projects that this one had approximately only a 6% chance of success.

Had such a compartmentalization process been employed, the ACA could have been implemented in a phased approach as each state's site came online.

As it is, I don't see how the current software can be adequately repaired providing a platform for future extensions and enhancements given the reports about the technical issues involved...

 

 

 

 

 

 
UberGoober
50%
50%
UberGoober,
User Rank: Strategist
12/4/2013 | 1:22:22 PM
Re: Bidding system
Your comment would be valid if there was free and open bidding, but CGI was virtually hand-picked for the job, despite a less-than-stellar record on similar projects. 

Healthcare.gov was a big job, and not only does it not work well, but most of the back-end systems aren't even built yet.  This is utterly predictable.  Consider NASA, which got us to the moon in less than a decade but now can't get a man to LEO without hitching a ride with the Russkis. Sclerosis is well and truly set into the federal bureaucracy.

Today, gubmint is bad at almost everything, efficient at almost nothing, and both good and efficient at absolutely nothing.  Those circles don't overlap at all!


And you clearly believe that things would have gone better had GOVERNMENT-HIRED programmers had done the work.  Wow!  See you at the DMV...

 
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Author
12/4/2013 | 2:34:07 PM
Project Management
Many of the decisions leading up to the rollout -- like the requirement for full shopping cart functionality during browsing -- were made by HHS policy makers who didn't heed warnings by the techies (or didn't ask) how that would impact the user experience downstream, or worse (what happened) how it would impact the performance of the entire system.  It's a classic example of the business side not communicating with the tech side. In this case, the tech team was the  junior partner in the decision-making. It wasn't until Jeff Zients took charge that the project was righted. 
WKash
50%
50%
WKash,
User Rank: Author
12/4/2013 | 3:49:42 PM
Re: Fix HealthCare.gov with a new site that is highly compartmentalized...
Steve, thanks for weighing in.  But to your point about insourcing vs outsourcing: Government's record using in-house talent to lead big IT projects is hardly encouraging. Even the Redskin's record this season looks better by comparison. What the administration (and CMS) needed was a much stronger project management team, a more competent lead integrator, a smarter, more modular design as you suggest, and more rigorous testing, among other things.

One other point worth remembering: When plans began for HealthCare.gov three years ago, is it was a guessing game on how many states would defer to the feds to manage their insurance exchanges. The feds should have been prepared, but accommodating 36 states -- each with their own set of health care rules and providers -- clearly made the task more complicated and the deadline more challenging. You may be right, creating compartments might have also compartmentalized the problems, and the expansion easier. But it's not a given.  What is a given is that the management team was not up to the task.
efarstad276
50%
50%
efarstad276,
User Rank: Apprentice
12/4/2013 | 4:35:08 PM
Data security first
Thanks for the article. I feel passionately about this one: data security is top priority. Improved functionality and speed mean nothing in the light of comprised data security. To know that the site had not passed internal security tests, and roll it out anyway on Oct. 1, was at best irresponsible and at worst criminal. So I say make the data secruity tight, and do all the security tests, before doing anything else.
Steve Naidamast
50%
50%
Steve Naidamast,
User Rank: Apprentice
12/4/2013 | 4:59:07 PM
Re: Fix HealthCare.gov with a new site that is highly compartmentalized...
I agree with you that management was clearly not up to the task but when the question was posed as to how I would fix the issue at hand I answered it from a software engineer's perspective.

As to your contention that doing the work in-house has also yielded poor results this may be so but it is also not a given on all such projects.  For example, the FBI has had historically poor performance when working with IT solutions for their work.  On the other hand, if you review the comparisons between the development of the F-16 and F-35 fighter aircraft, you will find a world of difference in terms of results.  Where the F-16 was primarily governed by government, in-house managers, the results were fantastic.  On the other hand, the F-35, which was in a sense outsourced in the sameway that the HealthCare.gov web-site has produced horrendous results.  So you can't always go by a generalization for all government capabilities as being poor with large project work.

I also agree with you that the government should have been far more prepared to handle a dynamic situation where some states would not participate and others would.  However, I do not see this as a technical or management issue but one of general incompetency.  However, handing off the majority of such work to outside contractors only made the situatioon worse simply from a communications standpoint let alone all the other negatives involved.

In this respect I agree with you that from the start this was specifically a management problem but in software engineering it almost always is...

 

 

 
Page 1 / 4   >   >>
2014 US Salary Survey: 10 Stats
2014 US Salary Survey: 10 Stats
InformationWeek surveyed 11,662 IT pros across 30 industries about their pay, benefits, job satisfaction, outsourcing, and more. Some of the results will surprise you.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest - July 22, 2014
Sophisticated attacks demand real-time risk management and continuous monitoring. Here's how federal agencies are meeting that challenge.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.