The Web Development Triangle

All of our contracts with our clients are ongoing monthly engagements. Very rarely do we pursue a fixed project and almost never 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 is learning, that’s a path that will lead to missed expectations.

To try and keep clients projects on time, we separate requirements into must have (meeting the business results) and nice to have (optional enhancements). We also don’t ever schedule are 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 which designs, builds and launches websites for many top Fortune 500 companies. Robert has been keeping tabs on the difficulties that has run into and has provided 5 key reasons for the failed launch.

  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).
  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.
  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.
  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.
  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.

What do you think?

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