Key Points:
I'm usually involved with organizations quite early in their planning process for large website changes. Often the changes being discussed are clearly not possible to implement, or at least to sustain after they are implemented. Here are some ways to see if your plans are flat out laughable.
Laugh test one: Have you defined your project goals?
Sometimes it seems that teams are trying to define how to get there, but before they know where "there" is. This can be a difficult balance since you can go way too far the other way too by defining where you want to go in exhaustive detail (which also leads to problems with the second laugh test below). But fundamentally you need to determine what the goals are. How will you know you will achieve them? How are you going to approach how deeply you will support your goals now vs. the longer term? See more on defining a vision.
Laugh test two: At a high level do you know how you'll pull this off?
There's often a scapegoat as to why the website isn't working now. Complaining about the CMS is fun for example. But usually the problems are more complex, and just swapping out the CMS may lead you right back to where you are now. Try to dig into why your current site isn't working in order to avoid the same problems from happening again after your website transformation. Consider at least the following aspects: website governance, IA, processes, metadata, standardization levels, how far publishing is distributed, major system capabilities that are required, content strategy, the team, and design.
Another way to look at this is that you have some control knobs at your disposal. The most important knobs are: the weight of what you are moving (such as the amount of content), the distance you are traveling (the gap from where you are now to where you are attempting to go), and the quality you are attempting. Instead of blindly going forward without planning these, tweak those knobs throughout your planning (graph where you are on the weight / distance scale).
Laugh test three: Will you be able to sustain quality and make changes after implementation?
Teams are usually far too focused on the launch date. Not only does this lead to immediate quality issues (by broadcasting a specific launch date, teams are more likely to push forward with the launch even when they know there are problems cropping up at the end), but more importantly it orients the team in an unproductive direction (looking at your web presence as something that should be project managed when it should also be product managed). In early planning, make sure you are clear about the implications of any shortcuts you plan on taking. For example, if you are not attempting to standardize similar sites while you are rolling out big changes, then it will make subsequent site-wide changes more difficult int he future. Also, when setting the stage for the project, make sure to emphasize with all stakeholders that you aren't shooting for one-time changes, but that everyone will be expected to maintain quality. At the most concrete level, will you even have the resources needed to maintain your web presence? If not, then consider a more modest goal.
Example: Slicing and dicing content while distributing content entry
Several times now I have seen organizations who are early in their website replatforming process and there are high expectations for both a) more distributed content entry and b) information automatically flowing to a wide range of topical pages. Both are possible, even together, but very difficult (slicing and dicing content requires good metadata, and that's even harder when more people are tagging). The point here isn't to say not to attempt difficult things, but that the implications of those decisions should be considered. Looking at each of the laugh tests above, in this example the clear vision will be absolutely essential. This is because the vision should to drive the complexity of the taxonomy, and it's extremely easy to create an overly-complex taxonomy (see this case study and more on matching the metadata complexity). Also, if the vision does not clearly require the additional complexity, then this requirement should be dropped. On to the second laugh test, the real question here is how you will implement topical pages with distributed content. Here you may tweak the quality control knob to a level that you can implement. But perhaps the third laugh test is the most critical, and easiest to overlook: how will you continue to train the publishers to maintain the quality levels of the topical pages? How will you track that quality over time?
What to do if your plans don't pass the laugh test
Luckily, it isn't that big a deal if your plans don't pass the laugh test! The main thing is to just STOP, DROP, and ROLL. By delving into the three questions above more, you can tweak the vision and broad approach (so that it does pass the laugh tests) before proceeding. The key is to not blindly go forward once you realize there are problems with your early planning.
