All of our contracts with our clients are ongoing monthly engagements. Very rarely do we pursue a fixed project, and rarely do we guarantee the timeline. That may sound scary to some, but the issue is that the goal shouldn’t be the date of release, it should be the business results. Our job is to get our clients business results, not take shortcuts to make launch dates. As Healthcare.gov is learning, that path will lead to missed expectations.
To try and keep clients’ projects on time, we separate requirements into must-haves (meeting the business results) and nice-to-haves (optional enhancements). We also don’t ever schedule completion at the time of release since we know there will always be some changes needed.
Robert Patrick is CEO of PhD Labs, an agency that designs, builds, and launches websites for many top Fortune 500 companies. Robert has been keeping tabs on the difficulties that Healthcare.gov has run into and has provided five key reasons for the failed launch.
- 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 variables. In this world, just about anything can be created if there is enough time and money. However, anyone building a web application should choose, upfront, 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).
- Launching with the finish line in mind instead of the starting line. Web applications should be seen as a project that will start and evolve. Building what is essential and mandatory for today with growth and evolution in mind is always better.
- Too many vendors are 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, etc. Imagine if we had 55 senates, each tasked with solving a portion of the problem.
- Information Architecture is not taken seriously. Often, large agencies will ask vendors to submit a bid on an RFP and altogether 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.
- Not enough time for Quality Assurance. 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 costs a lot of people their jobs.