People are hotly divided over the Healthcare.gov crash. Some wonder how something so important and funded to the tune of $300M could have such a disastrous launch. Meanwhile the “doomed to fail” camp points out that most IT projects fail, so why should this be an exception? 

Both sides miss the point. Healthcare.gov didn’t fail because of tech challenges, and the high failure rate of IT projects owes more to antiquated methodology than technology. The red flags -- bugs, lack of testing, changing requirements, lack of communication with executive sponsors -- are problems that plague most projects. The good news is that they can be addressed, even in large government projects. To understand why it failed, look first at how to do it right. 

Countering “Death by Bureaucracy” through an Executive View
Quite frequently IT projects suffer death by bureaucracy -- conflicting objectives, poor communication, misaligned efforts, unrealistic or unclear expectations. It’s no surprise that, as Patrick Thibodeau points out, state and federal projects are notorious for “blowing up” -- nobody does bureaucracy better than government. 

Bureaucracy, however monolithic, may be countered by aligning parties that naturally exist in a state of incongruence. As Jim Collins stated, “...the purpose of bureaucracy is to compensate for incompetence and lack of discipline--a problem that largely goes away if you have the right people in the first place.”

At Bluewolf we do this through an “Executive View” process which starts with identifying the project’s key stakeholders and working with them to agree on common success criteria. This becomes a beacon -- a unanimously agreed-upon framework that gives the project shape, and a means for resolving the inevitable debates. 

In this case, stakeholders can agree that Healthcare.gov should give Americans transparency and easy access. The current reality: confusion and inaction. Did some know it would fail? Definitely. Did they voice concerns? Assuredly. That such a project was rushed to beta despite warnings is a glaring indicator of stakeholder misalignment, and lack of balance between the three guiding points of any IT project: time, budget and scope of work. 

Understanding the Project’s Natural Limits
Just as we’re bound by the laws of physics, no project can exceed the parameters of its timeframe, budget and scope of work. You must look at these factors and ask: where is there flexibility, and where are these fixed? If the deadline can’t move, the project may need added resources. If resources are sapped, you’d better push back the deadline. 

With Healthcare.gov it appears that the timeframe was perceived as inflexible. If stakeholders had been aligned, they could have asked if there was flexibility regarding budget or scope of work -- if not, they would have realized they had no choice but to delay rollout. 

It’s simple, but not easy. Alignment isn’t the natural state of human organizations. We’re not ants or bees -- for us, alignment is only the result of concerted and consistent effort. 

One telling misstep was implementing a mandatory login feature late in the process. Of course, the fact that now no one can log in makes the idea of rushing such a requirement seem irrational. Those running Healthcare.gov aren’t irrational -- they’re misaligned.

Was this feature critical to success? If so, it should have been a point of early discussion, which it clearly wasn’t. Without a planned effort, bureaucracy defeats the Executive View and the project falls into misalignment. If stakeholders were aligned, the login requirement would have been included in the project’s success criteria. If, by chance, it emerged later as an issue, it would have been weighed in terms of how it would affect timeframe, scope and budget, and the stakeholders would have agreed on action that best served project goals. While I can’t say for sure what that decision would have been, I’m certain they wouldn’t have launched Healthcare.gov in its current form. 

Identifying the Limits of the Technology
A key component of the Executive View involves assessing the limits of your technology. The failed rollout resurrects the cloud vs. custom-built infrastructure debate. Security is the most frequent argument against the cloud, and people assume that the government can create something much more secure than any cloud vendor. However, it’s often overlooked that many cloud vendors offer tested infrastructure, allowing you to benefit from years of others’ mistakes. With Salesforce or Amazon Web Services (AWS), for example, login ability is already proven. When you build custom infrastructure, you bear the brunt of such testing.

Unfortunately, Healthcare.gov may not even be that secure. According to Computerworld’s Jaikumar Vijayan, the original October 1 deadline and the looming deadline for fixes may have created a security risk by leaving developers insufficient testing time, and the site is now likely a prime hacker target. Security takes time -- a luxury the administration doesn’t have now. Under the circumstances, you have to wonder whether it wouldn’t have been better to have used tested cloud-based infrastructure. Once again, stakeholder alignment will provide a realistic view of what you can do with the technology you’re working with -- you won’t get cloud speed with custom-built infrastructure. 

It’s the Era of the Customer...Even for the Government!
James Carville advised focusing on what’s most important: “It’s the economy, stupid.” In this case, it’s about the people who need insurance. Rather than focusing on whether or not Healthcare.gov fails, the administration needs to transform the way it engages its “customers.”

If it sounds odd to refer to citizens as “customers,” consider that this is new territory for government. We’re used to interacting via portals like IRS.gov and DMV.gov on the government’s terms. With Healthcare.gov, we’re interacting on our terms, and the government needs to adopt a customer-centric mindset. 

Technology drives only about 40 percent of customer success -- it’s also about managing public expectations through change. How does what you’re delivering comport with what they anticipate? Through executive alignment, you’ll understand how your success criteria stack up to expectations. If Healthcare.gov can follow this model, people will have had a more accurate idea of what they’ll get. Technology should serve the people  -- not vice versa. Healthcare.gov may for technological purposes be a data routing site, but it needs to be about customer relationship management -- more Burberry.com, less DMV.gov. 

If you are struggling with executive alignment in your organization, download the Bluewolf ExecutiveView Datasheet, or contact us.