Healthcare.gov and the Gulf Between Planning and Reality

Back in the mid-1990s, I did a lot of web work for traditional media. That often meant figuring out what the client was already doing on the web, and how it was going, so I’d find the techies in the company, and ask them what they were doing, and how it was going. Then I’d tell management what I’d learned. This always struck me as a waste of my time and their money; I was like an overpaid bike messenger, moving information from one part of the firm to another. I didn’t understand the job I was doing until one meeting at a magazine company.

The thing that made this meeting unusual was that one of their programmers had been invited to attend, so management could outline their web strategy to him. After the executives thanked me for explaining what I’d learned from log files given me by their own employees just days before, the programmer leaned forward and said “You know, we have all that information downstairs, but nobody’s ever asked us for it.”

I remember thinking “Oh, finally!” I figured the executives would be relieved this information was in-house, delighted that their own people were on it, maybe even mad at me for charging an exorbitant markup on local knowledge. Then I saw the look on their faces as they considered the programmer’s offer. The look wasn’t delight, or even relief, but contempt. The situation suddenly came clear: I was getting paid to save management from the distasteful act of listening to their own employees.

In the early days of print, you had to understand the tech to run the organization. (Ben Franklin, the man who made America a media hothouse, called himself Printer.) But in the 19th century, the printing press became domesticated. Printers were no longer senior figures — they became blue-collar workers. And the executive suite no longer interacted with them much, except during contract negotiations.

This might have been nothing more than a previously hard job becoming easier, Hallelujah. But most print companies took it further. Talking to the people who understood the technology became demeaning, something to be avoided. Information was to move from management to workers, not vice-versa (a pattern that later came to other kinds of media businesses as well.) By the time the web came around and understanding the technology mattered again, many media executives hadn’t just lost the habit of talking with their own technically adept employees, they’d actively suppressed it.

I’d long forgotten about that meeting and those looks of contempt (I stopped building websites before most people started) until the launch of Healthcare.gov.

* * *

For the first couple of weeks after the launch, I assumed any difficulties in the Federal insurance market were caused by unexpected early interest, and that once the initial crush ebbed, all would be well. The sinking feeling that all would not be well started with this disillusioning paragraph about what had happened when a staff member at the Centers for Medicare & Medicaid Services, the department responsible for Healthcare.gov, warned about difficulties with the site back in March. In response, his superiors told him…

[...] in effect, that failure was not an option, according to people who have spoken with him. Nor was rolling out the system in stages or on a smaller scale, as companies like Google typically do so that problems can more easily and quietly be fixed. Former government officials say the White House, which was calling the shots, feared that any backtracking would further embolden Republican critics who were trying to repeal the health care law.

The idea that “failure is not an option” is a fantasy version of how non-engineers should motivate engineers. That sentiment was invented by a screenwriter, riffing on an after-the-fact observation about Apollo 13; no one said it at the time. (If you ever say it, wash your mouth out with soap. If anyone ever says it to you, run.) Even NASA’s vaunted moonshot, so often referred to as the best of government innovation, tested with dozens of unmanned missions first, several of which failed outright.

Failure is always an option. Engineers work as hard as they do because they understand the risk of failure. And for anything it might have meant in its screenplay version, here that sentiment means the opposite; the unnamed executives were saying “Addressing the possibility of failure is not an option.”

* * *

The management question, when trying anything new, is “When does reality trump planning?” For the officials overseeing Healthcare.gov, the preferred answer was “Never.” Every time there was a chance to create some sort of public experimentation, or even just some clarity about its methods and goals, the imperative was to avoid giving the opposition anything to criticize.

At the time, this probably seemed like a way of avoiding early failures. But the project’s managers weren’t avoiding those failures. They were saving them up. The actual site is worse—far worse—for not having early and aggressive testing. Even accepting the crassest possible political rationale for denying opponents a target, avoiding all public review before launch has given those opponents more to complain about than any amount of ongoing trial and error would have.

In his most recent press conference about the problems with the site, the President ruefully compared his campaigns’ use of technology with Healthcare.gov:

And I think it’s fair to say that we have a pretty good track record of working with folks on technology and IT from our campaign, where, both in 2008 and 2012, we did a pretty darn good job on that. [...] If you’re doing it at the federal government level, you know, you’re going through, you know, 40 pages of specs and this and that and the other and there’s all kinds of law involved. And it makes it more difficult — it’s part of the reason why chronically federal IT programs are over budget, behind schedule.

It’s certainly true that Federal IT is chronically challenged by its own processes. But the biggest problem with Healthcare.gov was not timeline or budget. The biggest problem was that the site did not work, and the administration decided to launch it anyway.

This is not just a hiring problem, or a procurement problem. This is a management problem, and a cultural problem. The preferred method for implementing large technology projects in Washington is to write the plans up front, break them into increasingly detailed specifications, then build what the specifications call for. It’s often called the waterfall method, because on a timeline the project cascades from planning, at the top left of the chart, down to implementation, on the bottom right.

Like all organizational models, waterfall is mainly a theory of collaboration. By putting the most serious planning at the beginning, with subsequent work derived from the plan, the waterfall method amounts to a pledge by all parties not to learn anything while doing the actual work. Instead, waterfall insists that the participants will understand best how things should work before accumulating any real-world experience, and that planners will always know more than workers.

This is a perfect fit for a culture that communicates in the deontic language of legislation. It is also a dreadful way to make new technology. If there is no room for learning by doing, early mistakes will resist correction. If the people with real technical knowledge can’t deliver bad news up the chain, potential failures get embedded rather than uprooted as the work goes on.

At the same press conference, the President also noted the degree to which he had been kept in the dark:

OK. On the website, I was not informed directly that the website would not be working the way it was supposed to. Had I been informed, I wouldn’t be going out saying “Boy, this is going to be great.” You know, I’m accused of a lot of things, but I don’t think I’m stupid enough to go around saying, this is going to be like shopping on Amazon or Travelocity, a week before the website opens, if I thought that it wasn’t going to work.

Healthcare.gov is a half-billion dollar site that was unable to complete even a thousand enrollments a day at launch, and for weeks afterwards. As we now know, programmers, stakeholders, and testers all expressed reservations about Healthcare.gov’s ability to do what it was supposed to do. Yet no one who understood the problems was able to tell the President. Worse, every senior political figure—every one—who could have bridged the gap between knowledgeable employees and the President decided not to.

And so it was that, even on launch day, the President was allowed to make things worse for himself and his signature program by bragging about the already-failing site and inviting people to log in and use something that mostly wouldn’t work. Whatever happens to government procurement or hiring (and we should all hope those things get better) a culture that prefers deluding the boss over delivering bad news isn’t well equipped to try new things.

* * *

With a site this complex, things were never going to work perfectly the first day, whatever management thought they were procuring. Yet none of the engineers with a grasp of this particular reality could successfully convince the political appointees to adopt the obvious response: “Since the site won’t work for everyone anyway, let’s decide what tests to run on the initial uses we can support, and use what we learn to improve.”

In this context, testing does not just mean “Checking to see what works and what doesn’t.” Even the Healthcare.gov team did some testing; it was late and desultory, but at least it was there. (The testers recommended delaying launch until the problems were fixed. This did not happen.) Testing means seeing what works and what doesn’t, and acting on that knowledge, even if that means contradicting management’s deeply held assumptions or goals. In well run organizations, information runs from the top down and from the bottom up.

One of the great descriptions of what real testing looks like comes from Valve software, in a piece detailing the making of its game Half-Life. After designing a game that was only sort of good, the team at Valve revamped its process, including constant testing:

This [testing] was also a sure way to settle any design arguments. It became obvious that any personal opinion you had given really didn’t mean anything, at least not until the next test. Just because you were sure something was going to be fun didn’t make it so; the testers could still show up and demonstrate just how wrong you really were.

“Any personal opinion you had given really didn’t mean anything.” So it is in the government; any insistence that something must work is worthless if it actually doesn’t.

An effective test is an exercise in humility; it’s only useful in a culture where desirability is not confused with likelihood. For a test to change things, everyone has to understand that their opinion, and their boss’s opinion, matters less than what actually works and what doesn’t. (An organization that isn’t learning from its users has decided it doesn’t want to learn from its users.)

Given comparisons with technological success from private organizations, a common response is that the government has special constraints, and thus cannot develop projects piecemeal, test with citizens, or learn from its mistakes in public. I was up at the Kennedy School a month after the launch, talking about technical leadership and Healthcare.gov, when one of the audience members made just this point, proposing that the difficult launch was unavoidable, because the government simply couldn’t have tested bits of the project over time.

That observation illustrates the gulf between planning and reality in political circles. It is hard for policy people to imagine that Healthcare.gov could have had a phased rollout, even while it is having one.

At launch, on October 1, only a tiny fraction of potential users could actually try the service. They generated concrete errors. Those errors were handed to a team whose job was to improve the site, already public but only partially working. The resulting improvements are incremental, and put in place over a period of months. That is a phased rollout, just one conducted in the worst possible way.

The vision of “technology” as something you can buy according to a plan, then have delivered as if it were coming off a truck, flatters and relieves managers who have no idea and no interest in how this stuff works, but it’s also a breeding ground for disaster. The mismatch between technical competence and executive authority is at least as bad in government now as it was in media companies in the 1990s, but with much more at stake.

* * *

Tom Steinberg, in his remembrance of his brilliant colleague Chris Lightfoot, said this about Lightfoot’s view of government and technology:

[W]hat he fundamentally had right was the understanding that you could no longer run a country properly if the elites don’t understand technology in the same way they grasp economics or ideology or propaganda. His analysis and predictions about what would happens if elites couldn’t learn were savage and depressingly accurate.

Now, and from now on, government will interact with its citizens via the internet, in increasingly important ways. This is a non-partisan issue; whichever party is in the White House will build and launch new forms of public service online. Unfortunately for us, our senior political figures have little habit of talking to their own technically adept employees.

If I had to design a litmus test for whether our political class grasps the internet, I would look for just one signal: Can anyone with authority over a new project articulate the tradeoff between features, quality, and time?

When a project cannot meet all three goals—a situation Healthcare.gov was clearly in by March—something will give. If you want certain features at a certain level of quality, you’d better be able to move the deadline. If you want overall quality by a certain deadline, you’d better be able to simplify, delay, or drop features. And if you have a fixed feature list and deadline, quality will suffer.

Intoning “Failure is not an option” will be at best useless, and at worst harmful. There is no “Suddenly Go Faster” button, no way you can throw in money or additional developers as a late-stage accelerant; money is not directly tradable for either quality or speed, and adding more programmers to a late project makes it later. You can slip deadlines, reduce features, or, as a last resort, just launch and see what breaks.

Denying this tradeoff doesn’t prevent it from happening. If no one with authority over the project understands that, the tradeoff is likely to mean sacrificing quality by default. That just happened to this administration’s signature policy goal. It will happen again, as long politicians can be allowed to imagine that if you just plan hard enough, you can ignore reality. It will happen again, as long as department heads imagine that complex technology can be procured like pencils. It will happen again as long as management regards listening to the people who understand the technology as a distasteful act.

91 Responses to “Healthcare.gov and the Gulf Between Planning and Reality”

  1. Mike B Says:

    Why didn’t the government just give every citizen 1 million dollars in a flexible health spending account, clap twice, wave their hands and say job done. It would have benefited everyone far more than the eternal mess they have created.

    Great article btw, I see this daily at my job. We call it blinded by hubris.

  2. Peter Bachman Says:

    I’m surprise that no one I know has read the original RFI put out by CMS for the project. I wish I had before last summer. Go though the War Room notes, count the number of times they had issues with the Identity Management federation versus the old system that was working before the project.

  3. charleymd Says:

    It’s not just technology. I was a physician spending about half of my time on administration of a hospital department. The hospital administrators would come in with ideas, naturally involving physicians on the medical staff. When I tried to discuss the likely reactions of the physicians, I saw the same look of contempt on the administrators’ faces. “We don’t have to think about, or deal with, those jerks, that’s just your job. Just get them on board so our great ideas will work.” You cannot overestimate the contempt that managers have for those who can actually do the work.

  4. slarrow Says:

    Mr. Shirky’s comment about the importance of understanding the tradeoff between features, quality, and time rings a bell. I’ve always formulated it like this:

    Fast. Accurate. Complete. At best, pick two.

    It’s the dream that you can get all three that will trip you up. If you can’t understand that the third element always undercuts the other two, then you’re doomed to disappointment.

  5. Dave-0 Says:

    As written in the fantastically cogent Appendix to the Rogers Report on the Challenger disaster, Richard Feynman said “For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.”

    Time and again politicians (and management of all kinds and at all levels) have substituted wishful thinking for data and good judgement. We see in the Healthcare.gov only the latest instantiation of this. Einstein may have been right when he said the power of human stupidity may be infinite, but our power to deceive ourselves seems to be, for certain.

  6. Peter Harrison Says:

    Richard Feynman asked the engineers that worked on the Shuttle about their estimate of the probability of a catastrophic failure of a Shuttle. Their estimate was 1 in 200. Management however had a different estimate, by a factor of more than 10,000. Management said that the Shuttle must necessarily have a high level of reliability. It seems that this project had a similar disconnect between the engineers and management.

    Perhaps this is what might be termed the “Scotty Syndrome”, where Captain Kirk would tell Scotty the engineer that they need warp power in three minutes or the ship would be lost. Planning a big bang release of a major system is essentially planning to fail. Software development is a iterative process of modification and correction. It is evolutionary. Developing a new system wholesale in a tight time frame with high expectations and low tolerances for failure, along with hostile external players; it is hard to imagine how you could do more to set a project up to fail.

  7. Old fogey Says:

    For the life of me, I can’t understand why the President did not try out the website himself say a month before it was due to be unveiled to the public. Was he so not-interested in his “signature achievement” that he couldn’t spare a few hours (with a technical aide at his side) to see how the website actually functioned?

  8. DM Says:

    Having seen successes and failures in the federal IT space for 25 years this article really resonated with me. Maybe even 5 years ago the Administration would not have relied so fully on a web site to implement such a program. In an earlier time, applicants would have been directed to visit a local office in person or call into a service center to explore options and buy insurance. It says a lot about the advances of technology in delivering service to the citizenry that the web portal was the only option planned.

    So now if you put all your eggs in the internet basket you better really know how to manage the delivery of an IT-only solution … or be smart enough to hire someone who does. This was not so much a failure of the waterfall method as it was an exercise in leadership arrogance. Leaders were convinced if they could use new media to elect a president – how hard could it be to put a health insurance exchange into production? They fell victim to a plan that included the activity “then magic happens” at just the right time to bail them out.

    A really effective implementation leader would have identified key indicators to report out 18, 15, 12, 9, 6, and 3 months before go-live. This leader would have described the range of outcomes possible at each measurement interval and understood the downstream consequences of being out of tolerance. This leader would have demanded transparency in the reporting of results at each point to unite all stakeholders in corrective action. The program’s executive sponsor has a lot riding on this and deserves knowing the truth no matter how bad the news may be.

    This could have been a wonderful success story with the right leadership.

  9. buddyglass Says:

    “money is not directly tradable for either quality or speed”

    This seems false, since faster/bigger hardware is almost always an option. Certainly it’s true that a linear speedup won’t fix exponentially bad performance, but it’s not entirely accurate to say there’s no way to “buy performance”.

  10. J B L Says:

    Talk about history repeating itself, or failure to learn from the past, or the loss of knowledge passed down from older generations, call it what you will: commenter Charles Z says ‘One of the aphorisms frequently applied to project failures through overstaffing was, “If one woman can have a baby in nine months, nine women can have a baby in one month.”’

    Of course it was that very idea that was completely and widely debunked in Fred Brooks’ seminal book “The Mythical Man Month”, which has been edited and republished three or four times since I first read it in 1975. Of course Mr Shirky has not forgotten this essential bit of knowledge; he refers to this book directly in this very article. It directly contradicts, with evidence, the idea implied by Charles Z’s quotation. And with the exception of some people such as Mr Z and Mr Shirky, it seems to have been forgotten, especially by those in charge of projects like this one.

  11. Chris Wheeler Says:

    An interesting read. I always wonder how much of the issues were also caused by the classic thing I see a lot. This sounds more like a re-writing and streamlining of business processes, facilitated by IT systems. IT is part of that process, and if it is seem as a purely IT project, it is already well on it’s way to failure. Pure IT projects are much easier, and more rarely fail, but are rarely as powerful as business transformation (for good or ill).

  12. Some Guy Says:

    “I was getting paid to save management from the distasteful act of listening to their own employees.”

    “many media executives hadn’t just lost the habit of talking with their own technically adept employees,”

    I’m not that familiar with the history here, but this sounds like what W. Edwards Deming was trying to save American manufacturing from … fifty years ago.

  13. Scott Says:

    Denying this tradeoff doesn’t prevent it from happening. If no one with authority over the project understands that, the tradeoff is likely to mean sacrificing quality by default.

    World leaders are only this past decade realizing that political power cannot repeal the laws of economics. How long will it take for them to realize the same about the principles of engineering?

  14. DaveM Says:

    “Worse, every senior political figure—every one—who could have bridged the gap between knowledgeable employees and the President decided not to.”

    May I ask how you know this is so? Did you interview them, or read an interview someone else conducted? As far as I know, no one inside the White House staff has ever leaked any details about these internal discussions.

    Not trying to disagree with you, just trying to find out who’s talking, because that would be very helpful at this point. The “lid” on this project has been way too tight from the very beginning, and until people start talking, they are going to be “saving up errors” for the future, just as you say.

  15. Analysis: Bad Managers Ruined Obamacare | pundit from another planet Says:

    […] to dissect what went wrong. So far, the best take I’ve seen comes from Internet pioneer Clay Shirky, who notes that the politicians weren’t listening to the people doing the actual […]

  16. » Healthcare.gov and development Mike's Meandering Montage Says:

    […] Healthcare.gov and the Gulf Between Planning and Reality […]

  17. Shared: » Healthcare.gov and the Gulf Between Planning and Reality Clay Shirky | Brush Valley Brewer Says:

    […] » Healthcare.gov and the Gulf Between Planning and Reality Clay Shirky: […]

  18. Roy Ames Says:

    Thanks for the interesting article. I am an engineer who builds factory automation and was nodding in agreement with so many of the points, even though I had not thought of them in this way before. Whether I am designing the mechanical parts or programming a PLC, I often think of it being like a rock climber who sets anchors every few feet so that if he falls, he will not fall so far. I like building things up in little pieces to make sure each one works. I am also in agreement with Fran above. I love working for someone who has done real things this way too and run from those who only know how to spout faddish buzzwords like lean, six sigma and five s. I’m sure five s must stand for the five shits. If it doesn’t, it should for all the good that any of these things do for anyone, except for people who got rich making up this stuff.

    Question – Why didn’t the government just pay Google or Amazon to do their website and stay out of their way? Does anyone think that would have worked better? Why or Why not? I have not worked on websites, so I am really just asking to learn. Thanks!

  19. Charles Z Says:

    I worked in the IT industry for many years and found that owners and managers who’d come up through the programming ranks were just as willing as non-technical managers to sign off on unrealistic contracts and deadlines. One of the aphorisms frequently applied to project failures through overstaffing was, “If one woman can have a baby in nine months, nine women can have a baby in one month.”

  20. Tiercelet Says:

    @Fran

    The problem you’ve described is one that’s fundamental to technology, though. The reality is that the vast majority of helpful new uses for technology don’t involve doing anything novel or interesting. They involve applying an existing solution or technique to a new area. Sure, sometimes people get to work at Facebook and design high-availability low-latency distributed database systems… but most of the time, even on the prestige jobs, they’re munging together some existing APIs.

    Everybody thinks s/he’s a hotshot with brilliant ideas who wants to go out and do something new, but most of it’s been done better by somebody else already. That’s why there’s such a ridiculous profusion of JavaScript libraries and PHP frameworks in the world–too many people who love to code and are pretty good at it, not enough actual novelty.

    Beyond that, I think you need to look at the way our society valorizes start-ups–if you’re privileged enough and willing to work like a dog for something prestigious, you stand a reasonable chance of being able to swindle a pension fund out of a mint’s worth of investment capital for something idiotic, like a social networking plug-in for rating your dog, or potentially libelous, like a social networking plug-in for rating your dinner date. These are small enough to be knocked out pretty quick by reasonably competent people, but there’s a huge amount of money chasing them. On the other hand, to do healthcare.gov right–integrating at least 70 different independent database systems in both public and private sectors–you’d have to have a huge amount of domain knowledge, and willingness to knuckle down for a very long, hard organizational challenge. That’s actually quite a different skill-set from someone who develops SnapChat.

    You’re absolutely right on the tedious bureaucracy of government-sector work and the capriciousness of Congressional funding decisions. But I think it’s unfair not to look at the ridiculous complexity of the project itself–which in this case was literally too big to succeed–and of projects typical of the sector, as well as the outsized rewards being given to a certain kind of inappropriately privileged kind of web development.

  21. RAD Says:

    Although there is a possibility that the launch failure of Healthcare.gov was due to the attitudes held by the various stakeholders, I suspect that the underlying problem was/is technical in nature. For a high visibility failure involving technology, there has been very little discussion surrounding the technical nature of the problems. When technologies fail, **metaphor alert** people drag out their favorite straw man and beat him like a rented mule.

  22. Links 11/22/13 | Mike the Mad Biologist Says:

    […] reality elites failed to feel A Call To Democrats To Stop Sitting Back On This Business With Judges Healthcare.gov and the Gulf Between Planning and Reality CEOs Seeking to Slash Social Security Stumble Over Their Own Hypocrisy Bullshit Jobs (I would put […]

  23. Max Delwo Says:

    A great example of the ‘Waterfall’ methodology at work! I guess these folks never heard of the ‘Agile’ methodology! Shame.

  24. Assorted Links | azmytheconomics Says:

    […] Planning and government tech projects. Very insightful article and it rings very true to me in my own experience with government tech […]

  25. dogtired52 Says:

    Clear writing and good comments on the writing. Something is still bothering me, comes from Fran’s point on the late 20′s tech whiz who will go to Silicon Valley over DC any day. My eldest is now one of those geeks, his latest adventure with a new start-up just received strong VC backing and he is working day and into the night with a small team. They are all young, no gray hair. The founder and CEO is the old man at 32. They talk funny too, about clouds and nodes. I am fast feeling irrelevant in a fast changing world. Could Obama or any of us gray-haired mortals even ask the right questions of these new techies if we did communicate? Whew, now I’m dog tired, think I’ll sip wine…

  26. Publius Says:

    Love this! Also agree with Fran about why on earth would anyone good take the job but if the job included being listened to maybe more would want the job and we would get virtuous cycle improvements instead of just getting fail.

  27. MVP | The blog of Nathan Hunstad Says:

    […] developed was faulty, and there’s a lot of truth to that. For a particularly good argument, read Clay Shirky. A lot of it boils down to this: development today is incremental and iterative. healthcare.gov […]

  28. Hobacks 70 Says:

    Senior management in virtually all organizations, public and private, are seldom interested in actually directing and managing operations or projects—-that is very hard work, and senior management thinks it is below their pay level. So much in society doesn’t work as well as it could due to this disdain for actually doing the work to produce something well.

  29. John Fisher Says:

    I’ve been in software development for over 20 years and this is a terrific article. Tim O’Reilly posted a link on G+.

  30. From the Archives: 11/21/2013 Edition « whatsjohnreading Says:

    […] http://www.shirky.com/weblog/2013/11/healthcare-gov-and-the-gulf-between-planning-and-reality/ […]

  31. Laura Dean Says:

    Thank you for writing this. I work in the tech industry and can’t stomach the media’s response to the site issues.
    On a side note, I don’t agree with Fran’s comment. There were PhDs working as low paid data managers during Obama’s ’08 campaign and top product managers developing interactive during ’12 campaign. There are many talented developers/product managers/data modelers who would take a pay cut to work on something they believe in. Especially for those with enough life experience to know how important the Affordable Care Act is, even if it’s not an ideal solution.

  32. Dan Tienes Says:

    Great analysis. Another blogger refers to this as “magical thinking” – the notion that just wanting it done will make it happen. For my part, I’ve only ever had one boss that gets the trade offs, even if he finds it frustrating. Best boss I ever had.

  33. Gerald Ardito Says:

    Maybe it’s just because I have spent the morning, as I often do, reading about education “reform,” that I can’t help but connect your critique of healthcare.gov to attempts to “transform” education. I think the key is the point you make about the one way flow of information, and resistance to testing.

  34. Tom Pained Says:

    This was built to fail. One may suggest that it is typical Federal arrogance at work, or that is was a sinister conspiracy, but fail it did and fail it will and the consequences of this failure as public policy from beginning to end are roughly like being stabbed multiple times with a mechanical pencil by a bureaucrat and being left to bleed until the software works AND you pay your deductible AND you find a provider.

    http://www.bloomberg.com/news/2013-11-04/obamacare-expedited-bidding-limited-who-could-build-site.html

    The race to construct an online insurance exchange by Oct. 1 spurred the Obama administration to use an expedited bidding system that limited its choice of a builder to just four companies, including CGI Group Inc.

    CGI’s choice for the job came as the result of a bidding shortcut that may have cut as much as nine months from the time usually required, said Rod Benson, a former procurement director for CMS.

    End-to-end testing, the responsibility of Tavenner’s agency, didn’t begin until about two weeks before launch.

  35. Dr. Eric Lutker Says:

    I like the way you analyzed the problems with the role-out of the website but I think we can add some additional insight if we are cognizant of several psychological issues, hubris, grandiosity, and megalomania being among them. It seems to me that with IT as well as with all other areas of problem solving parsimony is a key issue to consider. The often used cliché, “Keep it simple, stupid” deserves to be kept in mind and those who forget this often end up with “Egg on their face”.

  36. Tom Winans Says:

    Great essay …

    The thought occurred to me while reading it that Mr. Obama’s program objective initially seemed to be born out of the desire to address those needing healthcare … not already having it. So one wonders why Phase 1 wouldn’t have been simply to address those without, learn what you learn, and improve from there to address the pricing of those that have but feel their insurance costs too much …

  37. Tom Winans Says:

    Great essay … and disturbing on many fronts.

    Sadly, there was a very natural phasing that could have occurred, I think … one of the original intentions of the program was to provide insurance for those without it … I wonder how much could have been learned simply by maintaining this focus until it was addressed …

  38. GR Says:

    This is one for the anthologies.
    Should be required reading for anyone taking degrees in computer science.

  39. CMeier Says:

    Healthcare.gov is *not* that complicated. The guts are basically 1) a simple web front end that stores a small set of per user info, 2) a rules engine that combines fairly static data about available plans with the particular data stored in 1 to provide cost data to the users, and 3) a messaging system that sends the data from 1 to the external insurance companies once the user has made their choice based on the results returned by 2. Toss in reporting and an interface for the insurance cos to manage the semi-static rules data and you are done.

    It could have been done by a competent team of less than 25 pms/business analysts/devs/testers in two and half years for under $25 million total including hardware and personnel costs. Where did they spend a half a billion dollars?

  40. Healthcare.gov and the Gulf Between Planning and Reality « BIZCATALYST360° Says:

    […] via » Healthcare.gov and the Gulf Between Planning and Reality Clay Shirky. […]

  41. hhoran Says:

    Clay’s comment about discovering that he was on outsider being paid to spare management the demeaning task of talking to its employees helps explains the explosive growth of high-end management consultants in the last quarter century. Back in the day, there was some value in the type of outsider intervention Clay describes. Management realized that internal rivalries and silos prevented change; middle managers were wedded to old technologies and progress; no one in operations or finance understood anything about the other and couldn’t communicate. But this presumed that job of senior management was to identify and fix the problems that had developed under its watch. The few companies open to problem-solving didn’t create a large enough market for consultants. So the business, led by McKinsey, evolved from delivering bad news to telling senior management what it wanted to hear. To actively creating/supporting the alternate reality within the senior management bubble. Which helped significantly widen the cultural gap between them and employees, which was critical if you are designing compensation schemes based on rigged measures of short-term performance, and need to lay off thousands in order to meet those targets. Many of the large consultancies core business is to serve as a praetorian guard for the hanful of people at the top. Which explains why hourly fees and total billings have skyrocketed, even though no one on the outside can see any evidence that these fees drive tangible improvements, and they often drive major debacles (i.e. Enron).

Comments are closed.