Comments
How Would You Fix HealthCare.gov?
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   >   >>


IT's Reputation: What the Data Says
IT's Reputation: What the Data Says
InformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business really views IT's performance in delivering services - and, more important, powering innovation. Our results suggest IT leaders should worry less about whether they're getting enough resources and more about the relationships they have with business unit peers.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Must Reads Oct. 21, 2014
InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
A roundup of the top stories and trends on InformationWeek.com
Sponsored 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.