Clay Johnson and Harper Reed write,
HealthCare.gov needs to be fixed. We believe that in a few days it will be.
A few days?
They suggest that the government should modernize its procurement practices and development methods. On that issue, I do not disagree. But such modernization is not a magic bullet.
Johnson and Reed have experience in using the Internet to help political candidates mobilize supporters. To me, that is not the same thing as building a complex, mission-critical system to support a business.
What I am pushing is the idea that success in building such a system is not a matter of finding a technological magic bullet. It is a matter of starting with the right kind of organization on the business side. If the government is going to operate the world’s biggest health insurance brokerage, then the government needs to set up a business organization to manage it, with clear lines of authority and communication. Yes, it doesn’t hurt to use the most effective development tools and methods. But show me an ineffective org chart in the business, and I’ll show you a systems project failure no matter what tools and methods they use.
[UPDATE].
Jeff Sients, the new Suit, is not talking in terms of days, but he still seems optimistic.
Zients said healthcare.gov will be functioning “smoothly” for the vast majority of users by the end of November
The Suits are now talking about a “punch list,” as though this is a house that you just bought and the builder has to touch up the paint in a few places. For all I know, that accurately describes the situation. The worry is that instead of a basically solid building they have another Silver Spring Transit Center.
Ezra Klein interviews Fred Trotter, a health IT specialist who steers away from government contracts. Some excerpts:
I realized I could figure out how to develop these very complex, very new software programs or I could figure out how to contract with the government…One of the jokes we have in health IT that doctors have no idea what they want and we’ve been giving it to them for years. And I think that’s a fair assessment of technology procurement. The government has no idea what it wants and contractors have been giving it to them for years…There’s a problem in government IT departments in general where you get somebody who got a job in their 20s and didn’t really have any reason to improve their skill set or change their approach over 20 years but now they’re in charge of a department. People think if you are a geek and a technologist and that’s the way it is. But if I knew what I knew four years ago today and that’s all I knew today I’d be out of a job.
Arnold – I share your skepticism, with a slight tweak. Yes, the org chart is part of the problem with the system “malfunctions” being only a symptom. However, in my professional experience across several different large and small companies I have frequently run into mini-messiahs prophesying about “the new technology system” and all of the problems it will fix. (This is usually any problem being discussed within their earshot.) Often, the org chart actually does have correct accountabilities, etc… but the system still fails. Why? The lack of a functioning business process BEFORE the system was implemented. The correct way to implement a new massive technology system is to first have a functioning business with rational business processes which your new system will then automate, streamline, etc… A technology system is a tool designed to augment and improve a business process. ACA & it’s implementers appear to have made the same mistake often made (and cruelly punished) in the real world – merging the technology system and the business process in their mind to the point that they can’t see the distinction and understand which part they are trying to fix at any time. This never ends well.
But they could use Agile. Agile would fix everything and also be more agile. Agile makes things work…. fast. This does not work. Agile is the fix.
(cf, the second to last paragraph of the original article)
I assume you are being sarcastic. But either way, could you elaborate?
Correct, I am not serious. The authors seemed to place an extraordinary faith in Agile development (http://en.wikipedia.org/wiki/Agile_development) methodology. The don’t really go into detail in the piece, just throw out the term, and that it is “already in use in the private sector”.
The impression is of a kind of magic process by which if only X is done (and it’s not too late!) everything would work.
These methods come and go quite frequently. Agile has hung around longer than most, mainly, I think, because it has so many mutually incompatible varieties that all still claim the word ‘Agile’. By experience, they tend to be imposed within organizations based on the current fashion rather than their usefulness and applicability to a particular project.
I happen to think that even the simplistic “Agile!” is a reasonable point in this circumstance. What the agile methodologies have in common is the rejection of big design up front (BDUP) and the corresponding replacement, if you will, of iterative delivery.
From an outside perspective, an agile methodology presents earlier and more often results that can be banged against, and with the feedback that is (constantly, iteratively) generated, the deliverable improves in the metrics that matter to the deliveree.
Unless you actually attack the tenets of Agile, your criticism is hollow.
I think that the point is that no software development methodology is a magic bullet. For a complex system, the business people get the system they deserve. If they are not organized, focused, and good at two-way communication with technical staff, no development methodology can succeed.
For the sake of accountability I would like to have them define, in advance, what their standards for success or failure are. Then we could at least agree if it fails.
That isn’t going to happen because the political nature of the problem is naturally more important to this administration than its technical nature.
The evaluative constituency they are concerned about is defined by the NYT, the Washington Post, Politico, et al, who they can reasonably posit are going to get antsy about giving Republicans ammunition for talking points with their coverage. They are not in the least worried about what Arstechnica and Wired are going to write. So they’ll pick something concrete they can accomplish within five weeks that as likely as not will have nothing to do with the larger systemic issues and run with that. The Times, the Post, et al will feel obligated to cover it as at least the possibility of improvement. The Republicans will likely overplay and over-hype the situation in the meantime. If that all comes together then they stand a decent chance of buying six months or more to fix some actual problems, or at least build a better Potemkin.
Any measure of progress they put forth, let alone something as binary as success/failure, will be chosen on this basis. Count on it.
It’s perhaps already started: http://www.washingtonpost.com/blogs/wonkblog/wp/2013/10/26/exclusive-the-feds-have-made-330000-obamacare-eligibility-determinations/
Note how the Post nicely elides the ambiguity between 330,000 calculations and 330,000 people.
The following is all too true about company managements, project administration, and final results.
The Parable of the two Programmers
Neil W. Rickert, University of Illinois at Chicago.
=== ===
[edited] Once upon a time, unknown to each other, each of “Automated Accounting” and “Consolidated Computer” decided that it needed the identical computer program.
Automated hired a programmer-analyst, Alan, to solve their problem.
Meanwhile, Consolidated asked a newly hired entry-level programmer, Charles, to tackle the job, to see if he was as good as he pretended.
(continued at the link)
=== ===
+1
With the notice that thankfully my company is not like that, which is why it is such a pleasant place to work.