ObamaCare Website: An Example of How Not to Manage Innovation

ObamaCareUnless you are completely disconnected from the world, you are undoubtedly aware of the issues associated with the rollout of the website for the Affordable Care Act, otherwise known as ObamaCare. My interest in this article is to explore how this “product introduction” illustrates many of the common pitfalls companies face in managing innovation.

Since the launch of this website on October 1, there have been increasing number of news articles and commentary on the problems (1).  I am sure we will learn more in the coming weeks, and there will be much finger-pointing for sure, but this product launch has important lessons for any senior manager responsible for their company’s innovation efforts.

Management Engagement

Most failure in new product development can be traced to management problems, and especially the lack of engagement by senior management (2). While this particular product introduction is obviously influenced by politics, I would contend the “senior management” in this case are clearly responsible. Even if the primary contractor is found to be part of the problem, senior management made the decision on who to hire, and chose to use federal agency employees to manage the integration.

According to those familiar with the project, there were warning signs months ago that the system was not working properly, and federal officials pushed ahead with the project despite these warnings from those most familiar with the project. Those working on the project knew that the October 1 date was set in stone, even naming it “the tyranny of the October 1 date” and felt the deadlines were unrealistic. For anyone who has managed large, complex projects, does that sound familiar? The pressure to meet launch dates is relentless, regardless of whether corners are being cut and quality sacrificed.

Not ListeningIn so many cases, management responds negatively to teams expressing reservations about the schedule due to technical issues. They just do not want to hear about the problems, and take the attitude that if the team just works harder, all will be well. Those bringing the problems to management are branded as “negative” and not “team players”. I often say there is a difference between being negative and being skeptical. Many times, those who are skeptical base it on experience with similar projects, and should not be ignored. Over time, if teams are chastised for raising the red flag, they will not do it in the future. Knowing about issues as soon as possible gives the organization more time to consider options.

Management Involvement vs. Leverage

Related to the discussion above about management engagement is the concept of management involvement vs. leverage. Senior management must be involved and engaged with major projects from the beginning. So often, management will not engage until late in a project when problems have gotten out of control. This is when they have the least leverage to affect change. They believe that once a project has been defined, they can walk away and the team can take it from there.

When the problems surfaced in the last couple weeks with the ObamaCare website, government officials stated that they were going to do whatever it took to repair the site including requiring teams to work 24-hour days. The President promised a “tech surge”.  For those who have managed complex projects, the natural tendency to throw a great deal of resources into the project late in the game may actually hurt rather than help. A “tech surge” at the beginning of a project is much more useful, but typically not done.

Complexity, Risk and Project Management

A key responsibility for senior management is understanding the link between project complexity and risk, especially schedule risk (3). According to reports, this website contains about 500 million lines of software code. By comparison, a large bank system might contain 100 million. It is estimated that to fix the problems, about 5 million lines of code will have to be re-written. The prime contractor has called the project “complex, ambitious, and unprecedented”. A federal agency took on the responsibility for making sure that the databases and software being designed by 55 different contractors were integrated despite the fact they had no expertise to do the job. Some key testing did not take place until the week before the launch, and it was clear there were going to be problems. If that is not a recipe for disaster, then I am not sure what is.

iterateA common way to deal with a complex project and high levels of uncertainty is to introduce incrementally, test on a small scale, learn and adapt. About a month before the launch, a group of ten insurers were asked to test the site and give advice. This group urged federal officials to delay the launch because of the issues. An insurance company IT executive stated: “We discussed…is there a way to do a pilot-by state, by geographic region?” Many of the state-run exchanges that are running successfully did just that.

Another reason to have rolled this out in an incremental fashion was the fact that the site was apparently overwhelmed with volume when it launched. I suspect those defining the requirements for the system realized the uncertainty in the site volume estimates that the design was to be based upon. Again, starting small, failing and learning fast, would have helped to ferret out some of these “unknown unknowns”.

Changing Specifications

A common problem with many projects is project creep and changes while the project is unfolding. According to reports, significant changes in the requirements for the system occurred seven times in the last ten months alone. Any complex project that undergoes significant scope modification that close to introduction is bound to run into problems. This project was no exception.

So in summary, the problems associated with this website launch is a very public example of the challenge any organization faces when managing very complex projects. Even companies skilled in managing these kinds of projects can experience problems (4). Improving the chance of success requires first and foremost that innovation is treated as a key business process and management is fully and continuously engaged. Management must understand they have much more leverage to affect changes early in projects rather than later when problems might be out of control. Understanding project complexity, risk, and the impact on project management is crucial. Finally, scope changes and project creep can introduce additional risk and uncertainty.

What other aspects of the challenges of managing innovation are illustrated by this website launch? Have you experienced similar problems at your company? How did you deal with the issues?


(1) I relied on the following three articles for information related to the ObamaCare website rollout:

  1. http://www.washingtonpost.com/national/health-science/health-insurance-exchange-launched-despite-signs-of-serious-problems/2013/10/21/161a3500-3a85-11e3-b6a9-da62c264f40e_story.html
  2. http://www.foxnews.com/politics/2013/10/22/report-claims-obamacare-website-builders-warned-issues-before-launch/
  3. http://www.nytimes.com/2013/10/21/us/insurance-site-seen-needing-weeks-to-fix.html?_r=2&adxnnl=1&smid=tw-share&adxnnlx=1382440491-TimNv8nT8m70PlzJmT7yYA

(2) See this article for more information: New Product Development (NPD) as a Key Business Process

(3) See this article for more information: How Project Risk Impacts Project Management in New Product Development (NPD)

(4) See this article on the Boeing Dreamliner: Managing Complex Projects: The Boeing Dreamliner

New Product Visions is a consulting company that helps organizations improve the effectiveness of their new product development processes. We specialize in small to mid-sized companies that manufacture highly engineered products. Contact us today about how we might help you!

Specialties: NPD consultants, new product development consulting, developing new products, new product development seminars, small business consulting, new product development expert, product development process, new product development strategies, integrating NPD for mergers & acquisitions, organizing for innovation, management role in NPD, project risk analysis, innovation management

4 thoughts on “ObamaCare Website: An Example of How Not to Manage Innovation

  1. Jeff, thanks for a really interesting article. You did a masterful job of identifying common patterns of behavior in executive leadership that set development programs up for failure from the very beginning. You have described the ObamaCare debacle with such clarity that it will serve well as a comprehensive case study of common development program management pitfalls.

    I would really like to see this program succeed in the long run, but a major fiasco during the launch phase could put jeopardize that outcome. That it is doing well with independent implementation in certain states is a hopeful sign.

    Soon to come will be punishment of the innocent, and promotion of the guilty.

    • Marv, it is just amazing to me how often organizations repeat these mistakes. In this case, it is similar to the difficulty any company faces when they launch a product that suffers from quality problems because it was rushed to market. Convincing customers to come back and try the product again takes much effort, reducing earning potential and quickly depleting goodwill that the company may have built up over many years.

  2. Just like launching a rocket , there are certain subtests/subroutines that must past while all eyes are on the launch. If those checks do not get the “green” light, the launch is aborted/delayed and rescheduled for another day. The team estimates the correction duration and also proposes the new launch date and time. This process is repeated until all lights are green and the launch (reattempt) proceeds. Smaller scale (incremental size) launches are performed prior to the bigger scale. This allows to more easily detect, identify system problems, correct them, learn from them and replicate the best practice. lThere are already “new product development” processed that clearly define “toll gate” reviews and “red flag” stages. An individual state size “health care” launch process was the apparently better starting point then systematically integrate the program. The right new product launch manager at the helm, clearly communicating to the stakeholders and audience is the most important piece of all to avoid confusion and unnecessary disappointments from the “program users”. It’s for them. The technology and program will then evolve at its natural and safest rate of success.

    • Guy, you are spot on. What amazes me that so many companies repeat these same mistakes over and over again. It is a good example of the “planning fallacy” where we ignore the problems we had with a prior project, and believe that this time will be different.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.