What does the Failure of Healthcare.gov mean about present Software Development Methods

The most important thing to recognize this was a primarily a failure of leadership and not the technicians who were at work on the deployment.  Whoever the primary stakeholders were they made a miserable decision to go ahead with failed deployment October 1.   It was ultimately up to them to ascertain whether or not the deployment would be sufficient enough and they missed it.   Clearly they failed terribly in arriving at a reasonably reliable assessment and paid severely in the resulting outcome.   This is well documented and many on both the Republican and Democrat sides have blasted this decision.  There is not a lot new to be said about this.  Sadly for them the vitrolic political conversation which has done little if anything beneficial has helped contribute to anything problematic occuring with government these past few years and their project was open season to be sniped on.    However there are some potentially useful things that those of us in software development can take away and hopefully learn from in order to avoid such a catastrophic outcome to our projects.  

First thing of importance is to structure your project in such a way that it is set up for success.   This means to identify the key players, the exact requirements of the deliverables and solution to be deployed.  It means setting up effective metrics and tools that allow for sufficiently tracking the progress and state of the project.   It means making sure the lines of communication between key players is open and effective and achieves the necessary results for success.  It means that key milestones are being met in a timely way on the project timeline.  It means that results are measurable and features and performance behavior are tracked.  It means that shipping dates and deployment dates must slip even if the market timing is not in our favor.    There are always setbacks and obstacles to overcome but it seems that the project managers of the HealthCare.gov project forgot these things.   There has been made much of the lack of transparency and open process among key teams of the development effort.

Instead of heading the warning signs when October 1st came the hapless Healthcare.gov project managners deployed anyway and were unprepared for the inevitable outcome of rage and frustration by nearly everybody concerned.   It maybe that they had no choice and were told that they must deploy or else by the White House.  Who knows but they deployed despite either the lack of indicators or in the face of contraindicators.  Then things got very uncomfortable very quickly.

What it means for us who chose to learn from others mistakes is that these things were avoidable.  We must set up our projects for success and not be pushed into arbitrary timelines.   One key thing to learn from the Healthcare.gov effort is the critical importance of identifying and confirming through testing the existance and actual functionality of service level agreement among independent and distributed services that the primary site (in this case healthcare.gov) is relying on to generate the necessary data to complete a transaction. 

What else can be learned?   I’m sure many object lessons can be highlighted.   I will stick with the obvious and key takeaway that for those of us in development that the primary lessson should be that we make sure we structure and plan and execute our projects in such a way as to set them up for success.   We need to create the necessary mechanisms for tracking the project and put them into place make sure to encourage and open up communication channels among the key players and get out of the way.  

To attempt to be fair to those involved with the Healthcare.gov project the reality is that they operate under many government restrictions that we do not see in private industry.   The regulations very likely caused unpredicatable delays and contributed significantly to their misjudgement and ultimate failure of their initial launch.