Wednesday, October 30, 2013

Healthcare.gov: Who - or what - is to blame?

I recently read something in the news that shocked me – they said the legacy of a President might be affected by the performance of a website. “Legacy of a President” and “performance of a website” don't even belong in the same conversation, let alone the same sentence. And yet, that was part of the discussion.

Of course they were overstating it a tad, as is the norm for news reporting these days. But it has had a tremendous effect on the public's perception of a critical component of Obama's presidency, and on the effectiveness of the Affordable Care Act itself. All because of a poorly planned software release.

How could this happen? It's certainly not for a lack of funds, with the website (and all the underlying integrations and data structures) reportedly costing at least $375 million, probably more. There were multiple large consulting firms, with hundreds of high paid and very smart architects and developers working on this project. And yet, the launch can be summed up as no less than an epic fail.

There's no easy answer. We watch Dr. Oz and Dr. Phil and expect all our problems can be solved with a simple pill or a simple platitude, but the problem here runs deep, and is not going to be solved easily. Real change requires real effort, and this is one of those situations where actual cultural change must occur if we have any hope of avoiding this kind of problem in the future. There will be plenty of finger pointing – this is Washington D.C. after all, and the political machine must be fed. But the blame lies on both sides, and there's no easy answer.

The people in charge will say the consultants and developers didn't tell them it wasn't going to be ready. They didn't escalate problems soon enough, and they didn't communicate the seriousness of the issues. The developers will say that they did tell them, but those in charge weren't listening, didn't want to hear it, and changed their minds on the requirements late in the game, unwilling to believe that those late changes couldn't be accommodated.

Odds are, they will both be right. Our industry is broken. There is a basic flaw in communication, and it causes far too many projects, small and large, incidental and critical, to miss their release dates or hit the date but suffer in performance and effectiveness. This communication failure is on both sides of the table. I've had the pleasure of sitting in a seat on either side, and I've seen this flaw at work from both perspectives.

The builders of systems – the developers, architects and engineers – fear that they cannot tell those requesting these systems the truth. They fear that if they tell them that the requirements they've been given (“Can't you just...?”) are far more difficult and complicated than they appear, the requester will simply find someone else who will tell them what they want to hear. If they want the work, they must meet whatever self created time line and budget the requester has come up with, and find a way through change management to make up for the misalignment between expectations and reality.

The requesters of systems don't want to hear the truth. They want to be told that they will get whatever they want (and can change their mind at any time) based on a time line and budget that makes them happy. When issues arise during the course of the project, they want to hear that it can be fixed and brought back on track without sacrifice. They often exhibit selective hearing, ignoring the caveats and focusing only on the positive. Group think often takes over, and what was obviously a disaster in the making in retrospect seems like a good idea at the time.

Over the next few blog posts I'm going to propose some ways to reduce this risk. But the reality is that we must change this culture from both sides if we are ever going to have a chance at getting past these sorts of issues. The problems plaguing Healthcare.gov isn't unique, simply the most visible and damaging example of a long standing problem. Until the builders believe they can come to the table with an honest assessment of the work, and the requesters both trust that this assessment is true and accept it, we have no hope of consistently getting software projects completed on time and on budget. The outcome of these problems isn't just a bad website. It can damage us all, right up to the President of the United States.

No comments:

Post a Comment