The rollout of the Healthcare.gov web site in October was a … pick your word. Disaster. Outrage. Embarrassment. Difficult. Suboptimal. Supporters of Obamacare are concerned. Opponents are experiencing a frisson of Schadenfreude. Whatever your political views, there are some important lessons to be learned for IT professionals. The Healthcare.gov launch is not the only example of a deployment gone bad. In the last two decades, private corporations have seen many failed projects.
It is time to relearn some of the basic lessons of system development. There are many of these, let’s focus on five.
No Big Bang
Many of us who managed enterprise software projects in the 1990s and 2000’s have been down this road before. One of the classic lessons from this period is to “Plan big, start small.”
Rolling out a CRM application to 5,000 people on three continents may seem like a small task compared to Healthcare.gov, but important lessons obtain. One of the things we should have learned in the last two decades is that it is better to do a gradual implementation than a single big bang. Software developers routinely do continuous prototyping. IT operations people should have learned to do gradual deployments.
This approach contains the damage from a failed implementation, gives the development and operations teams useful feedback, and can create a level of anticipation among users. Imagine if Healthcare.gov was deployed state by state. Start with a small state and then gradually move to the larger states over a period of months. By the time the site was available in California, Texas, and New York there would have been months of experience and time to fix problems. More importantly, people would have been eagerly waiting to get access to the site.
Reports vary about the way the US government chose CGI Federal as its primary development partner. (Oddly enough, when we went to CGI Federal to link to its URL we got a screen that said, “Site under maintenance.” Read into that what you will.) Some reporters have said that the contract was singled sourced for political reasons. Some blame an onerous government contracting procedure.
One thing is clear. The company’s parent, CGI Group, was terminated in 2012 by an Ontario health agency after the firm missed multiple deadlines and failed to deliver the province’s online medical registry. An early warning signal for Healthcare.gov? One would think so.
IT organizations are often reluctant to say no. As a result, new features, additional objectives, and more extensive rollout plans are often added after the original project scope is defined. Some of this is not just necessary; it is useful. Intelligent changes help tune the system for the user’s needs.
As a government project, the scope of Healthcare.gov is tied to law and regulation. Still, the scope didn’t just creep, it galloped. At some point, someone needed to say no. Someone needed to renegotiate what was possible and when. If that happened, it didn’t work.
The lesson for IT is to stand tall and say no to scope creep. When a project fails, no one remembers or cares that the scope changed. They just know the project failed and its your fault.
In real estate, the motto is location, location, and location. In IT, it is all about performance: not just the performance of A or B or C, but the performance of the complete system under load. Today, people have one question: “How could they not know it wouldn’t work?”
Skip over the conspiracy theories and political intrigue. Clearly Healthcare.gov did not undergo sufficient performance testing. For a system as complex has the Obamacare portal, this is not a simple task. Few application performance management tools are good at testing large, composite applications. They test single programs or technology stacks. They track transactions, but not across all hops in their complete journey. They don’t maintain the user or business context when they do measure transactions.
(By the way, Correlsene’s SharePath software tracks all these things.)
Still, they should have known. There is simply no excuse for not understanding when and why application software breaks.
In addition to saying no, IT organizations need to be politically free zones. Obviously, this is difficult in a government program. There is a tendency to hide difficulties from the political opposition and tell people what they want to hear.
Of course, this is also true in enterprise IT. Companies operate under the terms of the Golden Rule: Whoever has the gold, rules. IT never has much gold, and as a result, they are dependent on funding and goodwill from other organizations.
Few IT professionals are good at politics. The final lesson from Healthcare.gov is to get out of the game. Be forthright, tell the truth, tell it in person, and let the chips fall where they may. At the end of the day, Healthcare.com may be a political failure but IT is at fault.