You are here

Pilot

If you're going to do a large web site redesign or migration, you are probably already planning on conducting a pilot. One natural approach is basically to consider the first site / section you migrate as the pilot, but not take the time to respond to issues uncovered during the migration (which would reduce acceptance of the project). There are other easy traps to fall into, so what does it take to do a strong pilot?

1. Flex Important Muscles

A web site isn't just a pile of pages, but includes content, tools, configuration, relationships, account management, reporting, people and processes (see description). So you should not consider your pilot just a test of some pages, any of which on your site could be piloted as well as any other. What is to piloted or not piloted is a key decision, and may or may not mean piloting lots of pages. The steps to decide should be:

  1. Define the compelling vision for your redesign.
  2. Decide which components of your site are key to your vision.
  3. Pilot the highest-risk or most important items.

Note that this usually does not mean piloting the easiest pages, or just trying to plow through a lot of pages to show progress (see more on tracking progress).

Since on of the purposes of a pilot is to discover issues as early as possible, so you can either reset expectations or put in more resources, you want to pilot the parts that are most important to your effort. Otherwise, you will think your pilot was a success only to have a train wreck later.

2. Launch Actual, Live Site

The best pilot will be one that results in a site that real-live web site visitors can actually use. Not only will you get feedback from the most important stakeholders of your site, but many other production-only issues will be more obvious. Examples will be load/caching issues, URL redirection, and usage of your site that you were unaware of. But, even more important: you will be forced to work through all the issues to launch a site, rather than just having a couple people publish a few pages and declare the pilot complete.

3. Reserve Time to Respond to Issues

If you have a schedule that goes straight from pilot to mass migration, then the pilot won't be of much use since you won't have time to respond to issues you uncover. You need a step where you regroup and respond to issues found during the pilot.

Don't jump straight from pilot to implementation.
Diagram: Pilot Steps

Ideally, you will have the time to:

  1. Define with key stakeholders what needs to be changed/fixed before the full redesign or migration occurs
  2. Implement all those items that were agreed-upon with stakeholders prior to the full-blown migration

What the Pilot Will Do

The successful pilot should then allow you to:

  • Better estimate how long the actual migration or redesign will happen (see "why estimate")
  • Tweak the system, approach, expectations, and training
  • Enhance buy-in
  • Avoid some major roadblocks