What I find most fascinating about the failure of Healthcare.gov is that both sides appear to be testing the limits of how you can spin an event. The right is solidly on message comparing Obamacare to slavery, while the left argues that Obamacare is more than the disastrous website.
The first argument is just insane, but the second overlooks the reality that the front end of any system creates the impression of that system. If it doesn't work, then the system doesn't work for anyone using that front end, either. Put another way: It doesn't really matter how good something is if you can't actually get it to function.
Healthcare.gov was such a big disaster because the Affordable Care Act is President Barack Obama's signature piece of legislation, and it's been on constant death watch since being signed into law. Having the website blow up has a good chance of eventually ending the vendor, CGI, which did most of the work, not to mention the government careers of anyone with anything to do with a project so important that getting it right was a requirement, not an option.
The failure appears to have started right at the beginning. It makes me wonder if people intentionally caused this failure - which is certainly not unusual in companies or governments. I mean, CGI had just been fired for a spectacular failure on a similar project in Canada, missing three years' worth of deadlines and suffering security lapses. Why else would the company have been selected, let alone sole-sourced? CGI appears to have been massively underweight given the risk connected with this project.
I could see how CGI might have accidentally won a competitive bid. Simple inexperience can lead a vendor to underbid to get government business, then underperform or find the result unprofitable. As a sole-source bid, though, this means blame falls on the people within the U.S. Department of Health and Human Services (HHS) who forced the selection. Their process, not to mention their intelligence, is now in question.
In light of the failure of Healthcare.gov, let's look at four key criteria that help you determine if a vendor is qualified to run your IT project.
1. Make Sure Your Vendor Knows Your Business
While CGI has done government business, little of that experience applied to this particular part of government. The company clearly wouldn't have known the political problems that needed to be addressed.
The most important qualification - though often overlooked - is the vendor's experience with the business unit it would be working with. This means it knows the systems it must interface with, the butts that have to be kissed during development and implementation and, most importantly, the process for dealing with a crisis so that selecting that vendor doesn't become your problem.
Enterprise vendors develop these skills early - look at IBM, which has been doing it for a century - or die prematurely. One mistake of a significant magnitude can not only knock a vendor out of a segment but, thanks to IT events where people share stories, out of the industry altogether.
This qualification is ironically most often overlooked when an in-place vendor is already doing an excellent job but gets passed over for a new project. This is one reason EMC implemented its customer loyalty program: To make sure customers know what EMC is doing for them that a new vendor might be unwilling, or more likely unable, to do.
2. Make Sure Your Vendor Can Be a General Contractor
There are two classes of enterprise vendor: Those that can take over the general contractor role in a complex project and those that can't. The capability to be the general contractor, the firm that coordinates the others, requires a unique skill set. These vendors know that sometimes it's better for the relationship with their partners to take the blame for a problem that may be the partner's fault.
Experienced general contractors will go to extra lengths to make sure subordinate vendors meet their timelines and requirements; they know the crap will flow uphill and tarnish their image if they don't. One common mistake is putting in that role a company that isn't used to being a general contractor, only to find that, when disaster occurs, finger-pointing ensues. This still makes the fool who chose this vendor look stupid.
Large companies can generally look within to find out which vendors perform best as general contractors with the firm. This will meet both the first and second requirements in one motion.
3. Make Sure Your Vendor Has Done These Projects Before
This is actually less important than you'd think - a vendor that meets the first two requirements generally knows how to get resources after the fact to complete the project. On the other hand, you can get a subject matter expert, drop him into an unfamiliar company or industry and he'll still fail spectacularly because he doesn't know the unique process for success. Technology companies can learn new technologies far easier than they can learn companies or industries.
This doesn't mean that specific experience isn't important. Keep in mind, though, that someone learning on your job will always make more mistakes than someone that has learned on anther firm's nickel. This should also be a selection criterion, albeit one with less weight than the others.
4. Make Sure Your Vendor Knows the Cost of Failure
I wonder if CGI was selected because more qualified vendors, recognizing Healthcare.gov's high levels of risk, ran screaming from the project. (That's what I would have done). However, had HHS bid this project out to vendors that knew this section of the federal government intimately, and who succeeded regularly in working with it, it's unlikely any of them would have failed. They'd have known how to avoid failure and that the cost of failure would likely be their own.
That's important in large projects. But in one such as Healthcare.gov, it's more than important, it's non-negotiable. For most projects like this, though, price is often the top decision factor, since bidders actually believe that a cheap vendor is a good value. In this case, knowing that HHS got CGI at a bargain price wasn't any help whatsoever. It's something to think about carefully.
Now, if you see a project like this coming your way, it might be time to take an emergency vacation or medical leave before it ends up on your desk. There's such a thing as too high-profile. Sometimes the smartest vendor is the one that knows when to walk away. That, too, should be a big clue. You don't want to be the CIO forced to step down when all is said and done.
Rob Enderle is president and principal analyst of the Enderle Group. Previously, he was the Senior Research Fellow for Forrester Research and the Giga Information Group. Prior to that he worked for IBM and held positions in Internal Audit, Competitive Analysis, Marketing, Finance and Security. Currently, Enderle writes on emerging technology, security and Linux for a variety of publications and appears on national news TV shows that include CNBC, FOX, Bloomberg and NPR.
Read more about government use of it in CIO's Government use of IT Drilldown.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.