A Flawed Rollout but a Familiar Story

Tuesday morning on my way to the office, I saw this headline at the top of the front page of the Wall Street Journal: “Obama Admits Health Website Flaws“. If you read the article or scan related news about, you’ll notice a variety of reported issues. One sentence stood out as a personal reminder of some painful experiences: “the decision to require all visitors to the website to create accounts in order to browse its insurance offerings was made barely a month before the site was launched by the Obama administration.”

The reason this struck me is because something similar has happened commonly in many of the projects I’ve been a part of over the past few years. Now, to preface, I know very few specifics about the project, the complex team building the website, or the timeline for implementing it – but what I do know is that although changing requirements are common, they can be disastrous to the timing of a new project and the perception of its success. I imagine that the requirements and design of the site have been firmly determined for a long time now, so adding this requirement one month prior to launch seems like a last-minute change.  And even though the change was later rescinded (they mention on the site that the application process isn’t necessary to browse), it apparently led to a bottleneck as users trying to create accounts overwhelmed the system.

When issues like this happen, it’s easy to blame others (and reading the article, it sounds like each party placed some blame on the other), but at the end of the day, it is everyone’s responsibility to deal with a change of plans. In managing projects, there are always three constraints – time, scope, and cost – all of which impact quality. In this case, with one month to go until the launch of the site (and with all Americans required to purchase health insurance soon), time seems to be the biggest issue. When you don’t have enough time to solve a problem caused by a last-minute change, quality will suffer. In this case, it was the thousands of Americans trying to create accounts who were impacted.

If shifting requirements is so common, then how do you prevent it or at least limit its damage? Regardless of the methodology used to run the project, here are some actions that can improve your success:

  • Identify the product owner and decision makers up front through proper planning so that you can continually filter key decisions through the correct stakeholders
  • Communicate effectively through in-person interactions to reduce the amount of assumptions your team makes and to help reduce the impact of late changes
  • Quickly identify and communicate the impact of the change on the project’s time, scope, and cost

While it seems like there is time to fix the issues with, what customers desire is a working product. At this point, the product that has been created is not working – or at least it’s perceived that way. That’s the power of a last-minute change of plans, and the results can be damaging if the team is not equipped to deal with it.

Phone: 312-602-4000
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons