Don’t Buy a Lemon Website – Test Drive it Early and Often

It is often said that the car you drive is a reflection of the owner. Cars are one of the only products that you can truly make your own. There are virtually unlimited possibilities for makes, models, features colors and add-ons. You can buy new or used, green or gas guzzler, sporty two doors to family trucksters. When buying a car, you know the features you want and the models that appeal to your personal sense of style. With cars there are no lack of sources for research. You watch the commercials, read the brochures and reviews, customize your car on the website, and watch for cars on the road. But nothing compares to the test drive. That is where you get to try the car on. You have probably had the experience where you know what car you want until the test drive. Maybe you didn't like the ride, or the dashboard was not what you are used to, the seats didn't feel right or even the color didn't make you happy. No matter how many lists of features you've made and pictures you've looked at, nothing compares to a test drive.

Dude, where's my test drive?

Unfortunately, the traditional way websites are sold, there is no way to do a test drive - at least not in a way that allows you to fix a poor match without significant time and money. The lack of test drives is one of the main reasons so many owners are not completely satisfied with their sites when they first see them. This leads to change requests and significant project overruns. It would be ideal to allow owners to test drive their site before buying, but this isn't practical with a custom built website - or is it?

Traditional buying process

The traditional web development process precedes through a sequence of phases, each creating increasingly more tangible representations of the end product. The preliminary stage, requirements, focuses on written features. In the car buying world, this is equivalent to a checklist of features you want from a car. Do you want a convertible or a hard top, leather or cloth seats, a SUV, midsize or hybrid? The second phase, design, focuses on wireframes and visual design elements. In the car world this is equivalent to drawings of the car's interior and exterior. Maybe even photos of prototypes of what the car might look like. With the requirements and designs signed off on, a web project proceeds into development. Now the development team goes away, often for several months or longer, and they build the product. At the other end you get a working site. Now you get to do the test drive. The development team did a lot of up-front work, so the site should be exactly what you want, right? It will be if:

1. You specified all your requirements accurately during the requirements and design phases
2. All the requirements were documented correctly
3. Bullets and drawings accurately communicated the quality you expect from the website
4. The developers accurately follow the specifications
5. The developers gave themselves enough time and budget to do the work properly. E.g. somehow they provided an accurate quote based on preliminary high level requirements.
6. Your organization's needs haven't changed
7. You competition hasn't changed what they're doing
8. Your boss, collegues, stakeholders, users, and development team haven't come up with new ideas
9. You don't change your mind once you get to see the real thing
10. You don't change your mind just because you are human and humans like to change our minds

That is a lot of ifs. This list could go on for a while, but I think you get the idea.

Brochures cannot replace the test drive

Wireframes and technical specs go a long way to specifying site requirements. But they are often still too far away from the working product. One issue is that to create in-depth Big Design Up Front specs, and I am talking about the "nobody got fired for hiring IBM" level of specs, is prohibitively expensive for most projects. A high quality set of detailed requirements takes a few months to deliver and costs in the mid-five figure to six figure range. Since most projects don't have that kind of budget for generating paper documents, most use lighter weight specs. Often the main requirements get well documented, but a lot of little details get left out. Those details tend to turn into gotcha's by the end of the project. The second issue with paper documents is on the surface they are deceptively easy to read, yet it takes a tuned eye to see the dragons underneath. Experienced IT directors know how to interpret the docs and understand the challenges that sit below the tip of the iceberg. Yet for most web projects the sponsor is a marketing manager, communications director or other position who has not spent years building technical projects. While bullets of features and drawings are not the ideal way to communicate a project, we all can decide if what we like if we get to play with the real thing. Give me the brochure if you have to, but I won't know if I really want it till I get to take it for a spin.

Not just a test drive, but drives

What we need is a way to let the project sponsor drive the website as soon as possible. Then let them make decisions around a working website. Thousands of projects already are being done this way. It's a project management methodology called agile. At the beginning of a project a product backlog is created listing all the features. Every two weeks, the team takes the highest prioritized chunk of those features to work on. One of the requirements of agile is that at the end of the two week cycle the tasks that were worked on are actually usable and demonstratable. At the end of the cycle, the completed work is reviewed by the team and stakeholders. In other words, every two weeks the project sponsor can take the website for a test drive. After the test drive, the project sponsor gets to decide what to work on next. Most importantly they don't have to make decisions around abstract bullets of features or paper specifications of the final project. They get to make decisions based on actual working components.

Here, try out the cup holders. Do you like them? Do you want us to improve them or move on to the cruise control. Oh, you like Super Big Gulps. OK, we will have to make the cup holders bigger. Glad we didn't wait till after we built the whole car to find that out otherwise we would have some major re-engineering to do.

The project sponsor also gets to decide when the project is done and how much it is going to cost. Agile projects cost less and generate more satisfaction. You don't pay for a Rolls Royce when all you wanted was an Accord. You don't pay for features you don't need and the features you do pay for are efficiently customized for just your tastes. So next time, don't wait till you have paid for most of the project before being allowed to take a test drive. Test drive early and often with agile.