Five Key Reasons the Website Failed Miserably and Why the Blame Game Never Works
The U.S. political landscape has never looked more divisive than it has the past few months. But there’s one thing both sides can agree upon: The colossal failed attempt to launch HealthCare.gov. And rather than putting a laser focus on fixing the problem, many involved with the project are casting blame to ensure their interests don’t take the very public fall.
Unfortunately, a very common mistake is destined to cause a very large ripple effect in Washington. Robert Patrick, CEO of Southern California-based PhD Labs, which designs, builds and launches websites for many top Fortune 500 companies, lays out the five main reasons the launch of HealthCare.gov failed and what you need to know to avoid a similar fate.
Reason #1
Never, ever violate the “Time, Cost & Feature Set” rule. Think of this as a triangle, you must choose one point to be fixed and the other two variable. In this world, just about anything can be created as long as there is enough time and money. However, anyone building a web application should choose, up front, which is the highest priority. This sets the tone and focus for how a project should be launched. For example,
- Should it be launched only once specific features are done (money and time are variable).
- Should it be launched quickly (money and features are variable).
- Should it be launched with a budget in mind (time and features are variable).
Reason #2
Launching with the “finish line” in mind instead of the “starting line.” Web applications should be seen as a project that will “start” and then “evolve.” Building what is important and mandatory for today with growth and evolution in mind is always better than building with the intention of finishing at the starting point.
Reason #3
Too many vendors involved. It’s been reported that the Obamacare website had close to 55 vendors involved. Adding multiple vendors to any project can be a slippery slope. You can almost guarantee there will be issues with file versioning, art file discrepancies, art opinion discrepancies, project abandonment, and the list goes on and on. Imagine if we had 55 senates each tasked with solving a portion of the overall problem.
Reason #4
Information Architecture not taken seriously. Often, large agencies will ask vendors to submit a bid on an RFP and completely skip over the Information Architecture process jumping right into development without understanding or agreeing upon a scope. This is a huge, ugly, time wasting, money losing, mistake. It’s extremely valuable to architect as much of the application as you can upfront and be prepared to be agile and flexible on the things that couldn’t be forecasted well before you start programming it (this is like building a house without blueprints). Vendors are destined to run out of budget and start to cut corners if this is not done correctly.
Reason #5
Not enough time for Quality Assurance. It’s obvious this was a big downfall to the launch of HealthCare.Gov. They were working on a hard launch date (time is the fixed variable of the triangle in this case) and the features and budget should have been modified to meet the launch date with time for proper Quality Assurance built into the plan. This is a crucial mistake and probably cost a lot of people their jobs.
I do believe all the ideas you have offered on your
post. They are very convincing and will certainly work.
Nonetheless, the posts are too brief for novices. Could you please prolong them a little
from next time? Thanks for the post.