Submitted by David Hobbs on 10 June 2013 - 12:12pm
When considering big website changes, you have very powerful control knobs at your disposal. Instead of battening down the hatches and blindly going forward with your website redesign or replatforming project, first consider these major controls you have:
At its simplest, your website has a certain number of pages. How many of those pages contribute value to your site visitor? When making big changes, you have the chance to better focus your website, potentially dramatically reducing the size of your site. Depending on how deeply you will be modifying the content, you also will need to spend some time handling content during a migration. If that is the case, then the more content you have then the more effort you will expend on your website changes. Really the weight of your site is more than page counts, and includes other areas of complexity like the number of backend systems you integrate with. As with content counts, these other aspects are a weight that you may need to transform or recreate when changing your website.
The amount of change needs to be carefully considered when planning big improvements to your site. Remember the point here is the distance from where you are now to where you want to go. In other words, this is not on some absolute scale but relative to your starting point (what you have right now). If you already have a large technical team implementing cutting edge functionality, then going even further may not be a stretch. But if your team is currently having a hard time keeping up with weekly content updates, then adding some even simple collaboration for external users may be unsustainable.
For weight and distance, consider a graph showing your current weight (in this graph called labeled as complexity) and distance:
In this example, you are starting with a heavy (complex) site, and are also trying to make big changes to that already-complicated site. Ideally you want to try to keep your efforts down as far in the lower left of the graph as possible. Sometimes you just can't do that, but in general the goal should be moving to a simpler site and not trying to change everything at once. Use this tool to start seeing where you are on the complexity / distance graph.
Usually organizations end up backing into a certain quality level, and what this often means is that the quality suffers. I often frequently been in conversations where the technical team says something black and white about what is possible from a quality perspective, when in fact the content owners just need to understand the trade-offs in deciding upon quality levels. But there are always tradeoffs in quality. The biggest problem occurs when no one even talks about quality expectations, and only when people see the resulting site do they realize the mismatch in expectations.
How to use the knobs
The first step is to simply consider weight, distance, and quality. The next is to tweak each of these in order to come up with a manageable plan. One effective way to control these knobs is in phasing, where you start by implementing the aspects that most move you toward your vision. For example, you may start by using your current taxonomy, and then over time make it more nuanced. An advantage of phasing to control the distance is that you are then preparing everyone for ongoing quality changes to your site (immediately everyone is thinking in terms of phases). Note that all the knobs are related. For example, reducing the weight means that you have more time to make the remaining quality high quality. Similarly, if you decide on higher quality then that may drive you to attempt to make fewer changes (distance) to the site.
Submitted by David Hobbs on 10 June 2013 - 11:10am
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 somecontrol 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.
The 2002 Adaptive Path blog post Doing a Content Inventory (Or, A Mind-Numbingly Detailed Odyssey Through Your Web Site) certainly has staying power, and it was excellent when it came out. But times have changed, and I'm amazed how often the blog post is still referenced. In particular, one of the things you are after in your content inventory is to see the variety and patterns of your content, and that isn't necessarily about plodding through every page of your site manually. Here are some key reasons why you should think more innovatively about your inventory:
There are many potential sources of data for an inventory
The first question you should ask yourself is "why am I doing this inventory?" It may be for general exploration of your content, but chances are you have a specific need. Your specific need may require data that you can't get by clicking around your site from the home page. For example, if you are looking to delete content then chances are it would be useful to know how many pageviews the content is getting. Sources of data for an inventory include: the HTML as viewed by the visitor, how content is used by visitors (such as pageviews), the origin system of the content (such as the CMS), and the intent of the site / quality evaluation.
Even if you do decide that you need to have full inventory with each piece of content enumerated as a separate line in your inventory, this doesn't mean that someone has to click through every page to do the inventory. In fact, you can get a lot of value from automating the collection of the inventory. This doesn't necessarily just mean pointing some crawler / spider at you site either, for example it could query directly against your CMS.
Sometimes you want an audit, but sometimes an inventory is sufficient
As I see it, an audit implies some qualitative judgement on the content. In these cases, you certainly need a person to do that evaluation. But sometimes an inventory is sufficient, and these can be done in a more automated manner.
An inventory isn't necessarily a one-time endeavor
Sometimes an inventory really is an ad hoc and one time thing, but you should at least consider if you should create an infrastructure for an ongoing inventory.
Sometimes Excel isn't the best tool
Excel is great, and I frequently find myself using it. Again (and as always with any technology evaluation), it gets to what you want to accomplish.
Submitted by David Hobbs on 17 April 2013 - 5:37pm
Website product management is responsible for the ongoing, comprehensive quality of the website. This is not the same as project (or program, or portfolio) management, although I frequently find that people default to using these terms interchangably. These other PMs are also important, but the one that in general seems to be most lacking is product management. To help clients navigate whether they are treating their website as a product, I have developed the following table -- you can use the right side as a checklist to see if you are currently taking a product view.
NOT taking a product view
Taking a product view
Primary reason for undertaking a new feature is whether there are staff (and budget) to undertake it
Staff/budget only a part of the discussion, and long term cost (and complexity for user) always considered
Asking for clients (including internal clients) to give the requirements
Shaping the requirements, based on current request and broader needs
Working with clients to define requirements that can be delivered and tested in the near term
Submitted by David Hobbs on 16 April 2013 - 4:56pm
Website migrations fail more often than people are willing to talk about. There are lots of types of train wrecks, but they include abandoned projects, stalled projects, or slowly grinding projects. Although these all feel different for the participants and have different results (for example, the stalled project, although perhaps significantly delayed, could still finish), why they occur has some common features.
Common features of content migration train wrecks
Here are some top reasons website migration projects turn into train wrecks. Although every migration is different, this issues are common enough that you should make sure to watch out for them.
1) Expectations mismatch
For most everyone, migrating content from one system to another is a rare occurence. So this makes team members getting on the same page about the desired outcomes a challenge. Unfortunately, not sharing common expectations can mean that a train wreck is around the corner. For example, a common situation is for the technical team to say that the migration will be easy and for the site owners to just accept that at face value. Unfortunately, the site owners may expect things like the images to be resized while the technical team assumes the site owners will do this. The point isn't that one team is right and the other is wrong, but that not sharing a common understanding early in the process can mean train wrecks later. For example, in the case of the images if the site owners haven't set aside the resources to deal with the image resizing, and the technical team doesn't have the time to script it, then this would probably mean a stalled project since no one has the time to deal with it immediately.
2) Editors do not accept CMS
Sometimes editors just do not accept the CMS. This is a problem :-). In order to avoid this, editor needs should be part of the requirements in selecting and implementing the backend systems. Also, by phasing in changes you can ensure getting feedback as early as possible. Furthermore, you want to set up a strong process for taking everyone's input, which can spike when people strart using the CMS in earnest.
3) Resources don't match desired quality
Often there just aren't enough resources to match the quality you're shooting for. Pair this with #1 above and this really gets complicated. Perhaps one of the most important secrets of migration planning is that quality is much more subtle than immediately obvious (and not just a "yes I want quality" or "no I don't care about quality" question). The problem is that usually organizations don't carefully think about quality, throw some people (or tools) at the migration at the last minute, and then just take whatever quality they get. This means you might implement what's easy rather than what is important. The solution is to plan out carefully both the quality levels you are attempting to achieve, and estimate the effort it will take to get there.
4) Cannot implement to plan
Whereas #1 above is when things get implemented in a way that the team was not expecting, sometimes everyone is expecting the same thing but the team can't seem to implement it. This often occurs when the plan was not reasonable in the first place, and so at a high level you want to think through how easy that shiny strategy of yours will be to implement. That said, one thing that always helps is to phase in changes. Not only does this mean that each step is easier to implement, but that the team also has the chance to react to what works at doesn't so that everyone isn't strapped to a long range plan that isn't working (or that folks did not understand). In addition, if you deploy your big project in this manner then you can set the stage for continuing changes in phases over time.
What to do about it
Fortunately, there's a lot you can do to avoid these problems. Mostly you avoid this by planning rather than letting migrations surprising you. We'll look at some effective means of mitigating against these risks below.
Although often difficult to get agreement on internally, phasing in changes to your website has many advantages. Some of these advantages were discussed in #4 above since this does help to achieve a plan that can be implemented. This actually also helps with #1 and #3 above as well since every can more concretely see results earlier.
Validate the plan
Implementing a plan takes coordination across a variety of disciplines, and it certainly isn't just technical. Operational, process, people, metadata, content, and many other factors are needed to pull off big website changes. Rather than jumping in to defining an impressive-looking Gantt chart, start by validating at a high level whether your plan or strategy can be implemented. For example, if your new plan requires a more extensive taxonomy, then who will manage the taxonomy and how will this be done in a high quality manner.
Estimate, with discussions about quality, early
One of the most effective things you can do in your planning is to do a wild estimate of the manual effort of your migration as early as possible. This should be done in conjunction with a discussion of the quality levels you are attempting to accomplish. Regardless of whether the estimate is accurate, you are sure to drive productive discussions. See Content Handling Process: Asking the Right Content Migration Questions for more.
Considering editor needs should happen in two steps: 1) considering editor needs during the CMS selection and 2) on an ongoing basis. To consider editor needs in the CMS selection process, these should be imbedded in the scenarios that you use to evaluate different candidates. On an ongoing basis, you should define your product management process to include editor input.