Obamacare's website problems can teach us a lot about large-scale project management and execution.
By now nearly every American has heard about or witnessed the poor performance of healthcare.gov. Early on, only one of every five users was able to actually sign in to the site, while poor performance and unavailable systems continue to plague the federal and some state exchanges. Jeffrey Zients, the Obama appointee called in to fix healthcare.gov, promised on Oct. 25 that the site "will work smoothly for the vast majority of users" by the end of November.
Soon after the launch on Oct. 1, former federal CTO Aneesh Chopra, in an Aspen Institute interview with The New York Times' Thomas Friedman, shrugged off the website problems, saying that "glitches happen." Chopra compared the healthcare.gov downtime to the frequent appearances of Twitter's "fail whale" as heavy traffic overwhelmed that site during the 2010 soccer World Cup.
But given that the size of the signup audience was well known in advance and that website technology is mature and well understood, how could the government create such an IT mess? Especially given how much lead time the government had (more than three years) and how much it spent on building the site, (estimated between $300 million and $500 million).
This project failure isn't quite so unusual, unfortunately. Industry research suggests that large IT projects are at far greater risk of failure than smaller efforts. A 2012 McKinsey study revealed that 17% of lT projects budgeted at $15 million or higher go so badly as to threaten the company's existence, and more than 40% of them fail. As bad as the U.S. healthcare website debut is, there are dozens of examples, in both the government and private sector, of similar debacles.
In a landmark 1995 study, the Standish Group established that only about 17% of IT projects could be considered "fully successful," another 52% were "challenged" (they didn't meet budget, quality or time goals) and 30% were "impaired or failed." In a recent update of that study conducted for ComputerWorld, Standish examined 3,555 IT projects between 2003 and 2012 that had labor costs of at least $10 million and found that only 6.4% of them were successful.
Combining the inherent problems associated with very large IT projects with outdated government practices greatly increases the risk factors. Enterprises of all types can track large IT project failures to several key reasons:
-- Poor design or inappropriate use of new technology
Strong sponsorship and solid requirements are especially difficult to come by in a political environment (read: ObamaCare), where too many individual and group stakeholders have reason to argue with one another and change the project. Applying the political process of lengthy debates, consensus-building and multiple agendas to defining project requirements is a recipe for disaster.
Furthermore, based on my experience, I suspect the contractors doing the government work encouraged changes, as they saw an opportunity to grow the scope of the project with much higher-margin work (change orders are always much more profitable than the original bid). Inadequate sponsorship and weak requirements were undoubtedly combined with a waterfall development methodology and overall big bang approach usually specified by government procurement methods. In fact, early testimony by the contractors indicated a lack of testing on the completed system and last-minute changes.
The Business of Going DigitalDigital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.
InformationWeek Tech Digest August 03, 2015The networking industry agrees that software-defined networking is the way of the future. So where are all the deployments? We take a look at where SDN is being deployed and what's getting in the way of deployments.