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
Threaded  |  Newest First  |  Oldest First
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.

 
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.
Laurianne
0%
100%
Laurianne,
User Rank: Author
12/5/2013 | 11:03:15 AM
Re: Nothing to commend
Jen, it's not the total I question. It's how they select the contractors. The private sector learned long ago that using the lowest bid IT contractors often gets you what you pay for. The goverenment strings together dozens of such shops.
David F. Carr
50%
50%
David F. Carr,
User Rank: Author
12/4/2013 | 5:26:09 PM
Re: Nothing to commend
If the signup form data was at least captured correctly, it might be possible to go back and fix enrollments that were not transmitted properly to the insurance provider. The worst thing would be if it turns out the data of those seeking coverage was lost or hopelessly scrambled behind the scenes, even as the front end seemed to show them everything worked fine.

I agree the uproar over not getting access to the website will be nothing compared with what will happen if enrollments were irretrievably screwed up.
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? 
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. 
danielcawrey
50%
50%
danielcawrey,
User Rank: Ninja
12/5/2013 | 1:09:35 PM
Re: Project Management
This is such a complex issue. The project management of this was bad, but is that because of te IT behind it or because of government procurement process?

Then, consider the implications of shutting the site down. Knowing that security issues existed, a business would have likely removed all functionality until the site was fixed. But the Obama administration could not deal with that type of fallout, allowing those of us on the sidelines to continue to debate this debacle. 
StevenJ13
50%
50%
StevenJ13,
User Rank: Strategist
12/4/2013 | 5:27:47 PM
Re: Bidding system
Lowest cost sometimes applies even you are even "in the club". A handful of companies have been providing this exact type of system (less the integrations) who would probably not even be considered if it was a so called "full and open" competition.  This isn't just this project but any government project.  It awards those who play the game the best – not those with the best solution.
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...

 

 

 

 

 

 
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.
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...

 

 

 
WKash
50%
50%
WKash,
User Rank: Author
12/4/2013 | 5:14:34 PM
Re: Fix HealthCare.gov with a new site that is highly compartmentalized...
Steve, you're right to point out there are indeed many exceptions where government can, and has, managed projects effectively.  I point to an example just recently with Recovery.gov (Lessons From A Successful Government Data Site)

I do think that with heavy metal projects of the sort the military builds, where the technology isn't outmoded quite so quickly, and the expertise is great, the government is better equipped to lead/manager -- even though as we also noted, they can still blow it big time. (see: Lessons from a $5 Billion IT Project: the Air Force's Expeditionary Combat Support System.

In the end, I'm convinced that technology developments are moving so quickly, so dynamcially, that the government is better served 1) hiring enough of the right technology experts to know what's available and where the technology is headed; and 2) also hiring enough of the right program management and acquisition experts to commission and manage what's needed; but 3) rely on strong integrators who know how government buys and builds and manage them to get the job done.
David F. Carr
50%
50%
David F. Carr,
User Rank: Author
12/4/2013 | 5:54:52 PM
Re: Fix HealthCare.gov with a new site that is highly compartmentalized...
The compartmentalization you describe sounds a lot like the cloud architecture pods / "swim lanes" suggestion of the scalability consultants and authors we interviewed. So I'm not sure it's an approach that has really fallen out of favor (or maybe there's a distinction I'm missing).
Steve Naidamast
50%
50%
Steve Naidamast,
User Rank: Apprentice
12/5/2013 | 9:25:16 AM
Re: Fix HealthCare.gov with a new site that is highly compartmentalized...
Re: David F. Carr

Compartmentalization has fallen out of favor with many youmger technical personnel as it seen as repetitive.  If so, why not simply make a generic\reusable component out of such code?

I have worked in such environments where this reduction in duplicate code is fostered and the end result is that the "reusable components" become such a mess in an attempt to satisfy all requirements that the woirk ends up being as bad as the worst messes you can imagine.

The other problem with such a paradigm is that of the "ripple effect".  You go into a component to modify it for one appliaction's use only to find that another is suddenly failing when it makes a similar call.

From these experiences I tend to promote compartmentalization of code no matter how repetitive because I will always know that the problems will stem from a single source, the application or system where a specific copy ofthe code is housed.

This is also why I receommended the development of state sub-sites since there are going to be differences between state requirements and the insurance companies that are going to sell there.  And true, in some cases, you would find quite a bit of code being redundant but so what?  All of the issues would be solely from the state-site being developed without any contagion from any other area of development.  And you could, under such circumstances, sucessfully outsourced the work to as many contractors as required since each state-site would have been develkoped by a single group of developers concentrating on their own set of requirements.

Of course, as several other people have already posted, even under more preferable development conditions, a strong, disciplined, management team on the government's behalf would have been required.  Unfortunately, from the responses I have been seeing in the press, I am under the impression that the original management team just didn't seem to be all that interested in seeing this project rolled out successfully but this is just my own impression...

 

 

 
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.
phadley068
50%
50%
phadley068,
User Rank: Apprentice
12/4/2013 | 5:35:08 PM
Simplify ... and don't reinvent the wheel
I agree with those that say the government should have leveraged existing health insurance marketplace frameworks.  It still isn't too late to simplify the front-end (read specific suggestions on my blog at http://wp.me/p3TMI1-1q) so the tech teams can really focus on information security and back-end integration.  Ultimately, a simplified initial user experience will go just as far as an improved backend to improve customer (user) satisfaction.
David F. Carr
50%
50%
David F. Carr,
User Rank: Author
12/4/2013 | 5:47:17 PM
Re: Simplify ... and don't reinvent the wheel
phadley068, Thanks for sharing your blog post. Good suggestions there. The only one I would question is the "remember people when they come back" suggestion. Yes, that's a common and recommended good usability trick, but I'd hesitate to recommend that they do anything too fancy with user identification right now, given that security is one of the outstanding issues with the site.
HealthCareLove
50%
50%
HealthCareLove,
User Rank: Apprentice
12/4/2013 | 8:43:43 PM
Step back, change approach
The flow of the site has been improved. I echo the sentiment of simplifying the user experience so the tech team can focus on security and stability.

However, beyond that, we're still not addressing the fact that health insurance is cryptic to end users. For example the terms Bronze, Silver, Platinum, and Catastrophic do nothing to convey the meaning behind them. Instead of using arbitrary sounding plan levels why not immediately state what each level entails?

I suggest adding contextual education for the users. Use simple, concise language to explain the difference between copay and out-of-pocket expenses. Healthcare plans are complicated, but the site can be designed to make digesting all this data easier. The muddy information architecture compounds the perceived complexity of the site.

This education process should be part of the plan application - users should not have to read through multiple sites to be able to learn these things. People should come away delighted because they now understand what they're paying for and how the Affordable Care Act affects them. 

 
James W
50%
50%
James W,
User Rank: Apprentice
12/5/2013 | 8:53:03 AM
Goal setting
My first action would be to determine exactly what is expected.  It is hard to "fix" if you do not know what a fixed system does...
JohnD981
50%
50%
JohnD981,
User Rank: Apprentice
12/5/2013 | 10:10:08 AM
Does anyone even know what HealthCare.Gov is built on?
I confess I did not try very hard, but I found not a single statement anywhere telling us about the technology platform for HealthCare.Gov ...

Under the circumstances, I cannot imagine how anybody could comment constructively regarding what might be done to fix it.

 
David F. Carr
50%
50%
David F. Carr,
User Rank: Author
12/6/2013 | 11:46:05 AM
Re: Does anyone even know what HealthCare.Gov is built on?
We mostly asked about project management strategies. The architectural specifics are hard for anyone outside of the project to know in great detail, although this is an interesting resource:

http://www.civicagency.org/2013/10/learning-from-the-healthcare-gov-infrastructure/
WKash
50%
50%
WKash,
User Rank: Author
12/6/2013 | 12:53:37 PM
Re: Does anyone even know what HealthCare.Gov is built on?
An Operations Readiness Review, from Centers of Medicare and Medicaid Services, dated 9/4/13, shows a diagram broadly illustration what's used in the Presentation layer for end users (bulit using Apache RP, and Layer7 SOA gateway, using SAML2 assertion); an application layer that uses Jboss Enterprise Web Server and Jboss SOA.

More at: http://docs.house.gov/meetings/IF/IF14/20130910/101274/HHRG-113-IF14-Wstate-CampbellC-20130910.pdf

 
rprescott
50%
50%
rprescott,
User Rank: Apprentice
12/5/2013 | 10:37:37 PM
unintended consequences
Okay. ..Real quick.  Most of the experienced spectators expected just what they have seen... An amateurish product delivered by a hands-off amateur. His two claims-to-fame are low level legislative "voting present" public sevice and " community organizer" resume entries. He had nothing else, save Ivy league law degrees, and we turned our country over to him. My wife and I are doing our darndest to position our daughter and son to be able to persevere, but a boat-load of our posterity are going to suffer the consequences of the naive. We are praying for them.

 

 
oneilldon
50%
50%
oneilldon,
User Rank: Strategist
12/7/2013 | 9:52:34 AM
The Way Forward
Those pretending that the problems being encountered are glitches, kinks, or simply bugs to be fixed and hoping that the problems will simply dissipate with the relaunch need to cease their wishful thinking. It is time to insist on the professional management steps needed to get to the bottom of this and right the ship.    

The following ten steps are called for immediately:

1. Use of ACA website by customers seeking healthcare insurance should be terminated. 

2. Existing customer profile data, personal data, and decision data should be quarantined. 

3. The ACA website requirements foundation and technical architecture should be reviewed, assessed, and audited by a team of experienced industry experts.

4. The management, engineering, and process practices employed on the project should be reviewed, assessed, and audited by a team of experienced industry experts.

5. The accumulated Technical Debt on the project should be reviewed, assessed, and audited by a team of experienced industry experts.

6. A professional team should be charged with assembling factual analytics associated with assurance metrics, compliance metrics, noncompliance metrics, product engineering metrics, project management metrics, and process metrics. 

7. A full scale program review should be conducted to assess requirements, architecture, practices, and metrics. The review team should record its findings and consequences and provide recommendations and rationale for carrying the project forward.

8. A professional team should be charged with assessing Cyber Security vulnerabilities in accordance with the NIST Cyber Framework.

9. A professional team should be charged with assessing privacy and civil liberties vulnerabilities in accordance with the NIST Cyber Framework.

10. The completion date for these activities should be established as December 16, 2013.

 
oneilldon
IW Pick
100%
0%
oneilldon,
User Rank: Strategist
12/7/2013 | 10:09:25 AM
Affordable Care Act (ACA) Rollout: State of Failure
Video Comment
Pmasarik
100%
0%
Pmasarik,
User Rank: Apprentice
12/7/2013 | 10:34:47 AM
Its not like this was the first IT Project mankind attempted
There is some really great commentary posted on this site most of which hits the nail on the head.
---------------------------------------------------------------
As an Information Management & Technology professional for many years, what runs through my mind is.....WOW. Will wonders never cease?

So here it is, yet another failed IT Project - or maybe call it a project with IT failings - and a very publicized one at that making a horrible situation even worse and now there are millions of opinions to be listened to - and as we all know how useful that is.....NOT   

Its not like this was the first IT Project mankind  attempted


What is inexcusable is the failing to do it right from the beginning. When these things occur, and Phase-VI of the project gets underway - Hunt for the Guilty - it always comes back to the beginning where we find one big messy ball of over-managed-everything by people who should not have been involved to begin with, yet there it is...and a mind-set of 'we've done something like this before.. lets get started...we got a deadline to meet'
 
And to help with the 20/20 hindsight lesson lets see if we can get a peek at 
1). the envisioned end-state diagram/description.
2). the (actual) Project Plan as followed,
3). the published/approved Business Requirements
     document.
4). the published/approved Functional/Non-Functional
     document,
5). the published/approved Technical Design
     Specification
6). the published/approved Test Plan,
7). the published/approved operating environment  
     technical design..... 

and throw in the list of all the meetings held and lastly, the overall count of WHO worked on this project by role....

If this information only partially exists we have the smoking-gun. Sadly, these findings are TYPICAL when IT Projects go down the drain.  But we already know this intuitively - honesty will not be found here - all will be covered up or merely stated as 'oh we did all that....' 

yea, that ought to add up to $600,000,000+ US Dollars 
 
Resonating is the old sage...' there is never enough time and money to do it right the first time, but there is always enough time and money to do it over again.'
 
---------------------------------------------------------------
Smart a$$ comments by me? maybe -but its like déjà vu....again  
dogcat
50%
50%
dogcat,
User Rank: Guru
12/8/2013 | 10:19:17 PM
Re: Its not like this was the first IT Project mankind attempted
While it's true that the private sector has large scale failed IT projects, the cause of private vs public sector (and especially the Federal area) IT project failures have some significant differences, though some are the same. In the Federal government, high level agency or department heads are often political appointees, who have no or little experience in the agency, or managing large enterpeises at all. It's the patronage, or spoiles sytem. Recall in Katrina episode that former President Bush told America that "Brownie was dong a great job."

So, Number 1, incompetence at the highest levels. In the private sector, whild this does happen, it is much less frequnt.

Secondly, number 2, the Federal government's purchasing and expendiures are not based on the same principles as in the private sector. Federal procurement has an economic stimulus and social function, to support and encourage businesses. The procurement process is moribund in many, but not not all agencies. Large Federal contractors are making $Billions feeding at the Federal trough, while Federal employees are criticized.

 

Number 3, outsourcing. Given number 2 above, developing and nurturing in house Federal employee skill and competence is actually discouraged, in favor of paying twice as much for contractors, who will pass the buck and maximize their profit. In the private sector, one tries to minimize expense. In the current Federal set up, the contractor's goal is to increase costs.

Some folkes will be making a lot of money in over budget costs on this fiasco. The question is not techincal, or whether to shut down for repairs or fix in flight, but rather how can top government leaders be so incompetent? This is just one example.

 
dogcat
50%
50%
dogcat,
User Rank: Guru
12/8/2013 | 10:27:19 PM
It's a political/managerial problem, not technical
While it's true that the private sector have large scale failed IT projects, the cause of private vs public sector (and especially the Federal area) have some significant differences, though some are the same. In the Federal government, high level agency or department heads are often political appointees, who have no or little experience in the agency, or managing large enterpeises at all. In house career Federal employees who might have years of experience and organization domain experience and knowlede are ignored.  It's the patronage, or spoils sytem. Recall in Katrina episode that former President Bush told America that "Brownie was dong a great job."

So, Number 1, incompetence at the highest levels. In the private sector, while this does happen, it is much less frequent. The President and his agency chief clearly were not watching this high profile project.

Secondly, number 2, the Federal government's purchasing and expendiures are not based on the same principles as in the private sector. Federal procurement has an economic stimulus and social function, to support and encourage businesses. The procurement process is moribund in many, but not not all agencies. Large Federal contractors are making $Billions feeding at the Federal trough, while Federal employees are criticized.

Number 3, outsourcing. Given number 2 above, developing and nurturing in house Federal employee skill and competence is actually discouraged, in favor of paying twice as much for contractors, who will pass the buck and maximize their profit. In the private sector, one tries to minimize expense. In the current Federal set up, the contractor's goal is to increase costs.

Col. Mark Douglas' put down on our having a competent government in favor of feeding government contractors because of the 'inherant goverment' kanard is just a bogus red herring used to subvert govenment to become a lackie to coporations. It is not in the constitution. Eisenhower warned about the 'military industrial' complex, which can now be expanded to the 'business industrial' complex, or medical-business complex.

Critics of governement ought to at least realize why it is so imcompetent, because it profits many by being that way, and thus it is kept cripled to the advantage of some, and loss to others.


What is pathetic about this failure is that it is totally self inflicted by our highest level leaders.

Some folks will be making a lot of money in over budget costs on this fiasco. The question is not techincal, or whether to shut down for repairs or fix in flight, (those questions are moot, and techie questions, but not project mangement questions) but rather how can top government leaders be so incompetent and why have we allowed our governament to be taken over by corporations that have only their own private interests at stake? And how have we allowed our system to reward self serving interests while ignoring the commong good?

It's a total contradiction that a private entity, like a government contractor, with its own profit-seeking-at-all-costs motivation be able to deliver a service for the common good that is not to its own advantage. And, it's not that self interest profit seeking is bad, it's just deluded to expect action contracy to its own charter and interest.

 
David F. Carr
50%
50%
David F. Carr,
User Rank: Author
12/9/2013 | 1:36:00 PM
Re: Its not like this was the first IT Project mankind attempted
@Pmasarik, great commentary, thank you.
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.