Submitted by David Hobbs on 26 September 2009 - 11:32am
So you want big changes on your site. Should you stick with your current system to accomplish this, perhaps doing a simple redesign, or is it time to migrate to another system? This is such an important decision, but easy to just fall into one of two camps: "our tool stinks and a new one would solve our problems" or "we couldn't possibly move." So how do you go about making the decision? Two steps can help you decide:
- Inventory what you already have (and not just a content inventory).
- Rationally review the situation for each item in your inventory, and then decide if the advantages/costs of staying outweigh the pros/resources of migrating or not.
What is a site?
What – exactly – is a site? If we're talking about whether to move or not, what are we talking about moving anyway? First, the obvious two parts of any site:
- Content, which is either managed or unmanaged.
- Tools, which could include anything from a highly automated CMS implementation, to someone using a text editor and ftp client.
You will also have some/all of these:
- Configuration
-
- Templates that drive how pages are consistently generated (chances are, these are not implemented in a way that's a simple copy-and-paste). For example, on the Hobbs On Tech blog, all the blog entries are generated from the same template of the CMS, but moving the templates to another system would not be 15 minutes of work.
- Special functionality, including how search is configured or how page urls are handled.
- Platform / implementation architecture. You may or may not have a platform that helps, behind the scenes, in ensuring quality of your site.
- Relationships
-
- Metadata. Metadata is becoming more and more important to driving how pages work, and an important element of any decision of how to modify a site.
- Structured content. You may have something like a "book" content that has chapters, or some other content that has components that are highly related. Regardless of the technology, the relationship between the components (for example chapters and books) would have to be maintained in a migration, or might be very difficult to maintain in your existing system.
- Links. Links within your current site and with partners need to be carefully considered, so that you don't break links or inadvertently end up with duplicate content in a redesign or migration.
- Integration with other existing systems, both to and from. This can include generic interfaces such as RSS and XML, as well as highly customized interfaces internally or with partners.
- Account management
- Reporting
-
- Self-inspection, including how many content items are in the repository and ability to easily find and edit content.
- Analytics, including passing key metadata to analytics packages / services.
- People and Processes (not the "account" above, but real live people used to supporting and trained on your system)
-
- Publishing interfaces, including workflow.
- Existing training and support programs.
Obviously the different components could be sliced and diced differently, and complex sites will probably have other concerns. That said, the basic message is to consider all aspects of your existing (and desired) site when deciding whether to migrate to a new system or not.
The Inventory
To do an effective inventory, you will first need to define your compelling vision of what you want your site to be. After you have that, for each of the components of your site (using the above list as a start), rate each according to the following:
- For the completely as-is case, with no changes, how well is the current site supporting the Compelling Vision? Perhaps you leave the effort baselined as 0 for this case. Obviously, one of the items you may be after is reducing the ongoing cost of running the site, which perhaps you can capture in the People and Processes section (or you may decide to create a separate sheet to decide analyze the ongoing costs).
- Another possibility may be to tweak the current system toward satisfying the Compelling Vision. In this case, rate both how close each component will be to meeting the vision, and also how much effort it will take to get there.
- Repeat the ratings of how close the system would be to where you want, along with how difficult it will be to get there.
Even if you just spend an hour on this exercise, hopefully you will have a clearer picture of your situation. Here's an example spreadsheet (with 5 being the best/difficult, and 0 being the worst/easiest that's been started for a hypothetical site:
The Decision
This will almost certainly be iterative. For example, you may look at your original analysis and decide that maybe there is an easier way to improve the metadata in your current system toward your strategic goals. Or after going through the exercise once, you may realize that there would be content repercussions that you didn't anticipate until you thought through the analytics requirements. At any rate, to help you make a decision you can see how difficult each possible approach would be, and weight that against how strong you anticipate the end solution to be. In addition, you will have some documentation of how you came to your decision. You can also use this sheet as a reality check when you conduct a pilot of your approach. For example, if you see that modifying the templates in your current system during pilot is far harder than you anticipated, you can revise your estimates and perhaps re-evaluate your initial decision.
Related posts
You may also be interested in these blog posts:
Bookmark/Search this post with
Submitted by David Hobbs on 14 September 2009 - 5:44pm
How do you staff a large web site migration? In this blog post I'll review some of the roles needed in a migration. Remember, much of these suggestions are for a relatively large migration (and some of these roles may be ridiculous for small migrations). Also, there are many elements to planning a migration (see checklist), but I'll focus on staffing here. Note that the compelling vision is particularly important when talking about staffing, to make sure that you're aligning and motivating everyone.
Balancing Complexity and People 
First, let's revisit the fact that there really is an interplay between the complexity (along with size) and the people required for the migration. This may seem obvious, but you often have a choice between putting your web site on a diet and the general resources needed. The focus of this blog post is on people, so just keep in mind that if some of these roles seem ridiculous then perhaps you just need to confirm that the complexity you are attempting is possible with the people you have on hand (as opposed to, as the diagram at right is showing, having more complexity than can be supported by the team).
Roles You'll Need
Here I'll concentrate on the staffing required for the migration itself, rather than the overall web team required for continuing to run the web as an ongoing undertaking (the migration is just a step in the long life of your web site). In general the migration will be a burst of effort, where people are brought in temporarily, but it is essential to keep the team needed for the ongoing support as well.
Also, I'll assume that the content strategists, information architects, (graphic) designers, taxonomist, system architects, and other people involved in the definition of the project have already defined what needs to be defined. Of course, they will still need to be available for issues that arise during the migration, but I'll assume that the overall structure has already been defined and it's time to get migrating. The policies and standards should have also been defined by the policies and standards teams so that the migration will occur consistently.
Note that the roles below are roles and not necessarily individuals. In other words, you might have one person playing multiple roles depending on the size of your migration. In addition, some of the roles below might not even be necessary for your migration.
Internal CMS Product Manager
You'll need someone to be managing the configuration / implementation of your CMS, and I would argue that you should have someone "internal" doing this (rather than, for example, you systems integrator). This product manager works with the various teams to ensure a high quality implementation and defines the product. One of the most tangible and high profile tasks they'll undertake is owning the feature request process. The best source for more information on this is this article on Internal CMS Product Management.
Liaisons and Coordinators
For very large projects, coordinating across large organizations, you need to think about how two-way communications will occur between the core infrastructure implementation team and the various units within your organization. For example, if you run a worldwide corporation, then there may be five different regions to work with and hundreds of users of the CMS. Obviously you're not going to have all the stake holders communicating directly with the developers. In a large organization, you could consider a model like this:
This type of model may seem (and be) overkill for your particular organization, but when you start having a hundred-plus people who will be involved in the migration, you may need:
- Liaisons on the technical team, who know the technology and can hand-hold the business users on how to get the system to do what they need it to do. Also, they can help work with the business users to understand any special requirements they may have.
- The business liaisons help prioritize all the requests and general issues that their business users are having in order to make sure that the most important items are getting taken care of.
Content Specialists
A site migration / revamp is usually an important time to improve the content. There's a good chance it is also necessary. For example, if you never had topics-based pages and are adding them now, then you'll probably need new content. Here I'll just list the different roles:
- Content Publishers. These are the folks that do the initial migration of content from the old system to the new (if it is not automated), and, depending on the tools and what you are trying to accomplish, doing HTML modifications/transformations or tagging. This role in particular may need to burst during the migration.
- Editors / Writers. Some content may largely be cut and pasted, in a fairly mechanical fashion. Other content needs to be written. Obviously, you need access to writers/editors for the web to do this work.
- Subject Matter Experts. During the migration, depending on what you are trying to accomplish, you will need access to your content subject matter experts. If your site is about the nuances of tax law, then you'll need access to your tax law experts.
Other roles
Some other roles need less description, although they are no less important. You should make sure to reflect on whether you need these roles in your migration:
- Project Manager. Although the CMS Product Manager may play this role, you may need to have a separate person looking specifically at keeping the project moving forward according to schedule and budget.
- Developers. Who exactly you need depends on what you're trying to accomplish and the tool you have, but you'll need developers (whether in-house or outsourced) for configuration/implementation of large sites.
- Help Desk. Unless the business liaisons can handle the various issues the CMS users raise, you will need to involve your helpdesk. The helpdesk may end up passing a large volume of the requests to the liaisons at the beginning until the patterns of requests are understood (and the helpdesk has the knowledge needed).
- Trainers. All the users need to be trained on how to use their system (for their particular task).
- Executive Sponsor. Someone high up in the food chain sponsoring the migration. In particular, they need to articulate the compelling vision of the migration.
Which do you need?
I've put a little spreadsheet together to help you keep track of which roles you already have, which you need, and which you won't need:
As always, I appreciate any comments you might have.
Bookmark/Search this post with
Submitted by David Hobbs on 14 September 2009 - 12:30pm
Requirements are difficult. I should say good requirements are hard to put together. One thing to look for in requirements, instead of a shopping list, is the juice in requirements. Sure you may need a bag of oranges, but what you're really after is orange juice. Of course, you also need a knife, juicer, pitcher, glasses, and to know how to make orange juice. But really, orange juice on it's own really isn't that interesting a requirement since pretty much anyone can make orange juice. So ideally you want to dig deeper and define more clearly what kind of juice you are attempting (perhaps mint orange juice made at your table?).
Many requirements are written as if each item on a requirements list is a magic pill, where if you just take, for example, one pill of "orange" you'll wind up with juice.
Let's step back and start with a shopping list.
The Shopping List
Many requirements I see look something like a shopping list (not that difficult to put together):
If you were handed this, would you know what's for dinner? It could be:
- sauce
- lemon butter
- bars
- cookies
- muffins
It reminds me of the question you get on the plane: "would you like beef or chicken" when you have no idea how it's prepared. So in the list above, you can be pretty certain that you'll be eating something lemony, but you don't know if it's going to be sweet, savory, an accompaniment, or the main course.
Actually, you don't really know if it's going to be lemony. Perhaps lemons may be needed but you're not sure. Also, you may be using ingredients already in your pantry or refrigerator (perhaps lemon fried chicken?). Or the lemons could just be used to keep your apples from turning brown after you cut them. Or you could only be using the lemons to make lemonade. Someone in the house may have just said "I think we're low on butter" with no specific purpose in mind.
The Objective
What if you were handed a sheet that said "We're having your favorite tonight: lemon pancakes! To make the pancakes we need sweet butter, large organic eggs, those small lemons at the back of the store, and flour"? That's a bit more motivating, and something that everyone can understand and line up behind ("Junior, if you don't run over and get lemons we're not having lemon pancakes tonight").
Unstated Requirements, Important Details, Technique and Your Skills
So you get home, and find that you're the one making dinner. All you have is the objective (lemon pancakes) and the ingredients from the shopping list. No one gave you a recipe. And frankly you don't know your way around this kitchen. You look on the internet and find a recipe for lemon pancakes, but it calls for refined sugar which you're avoiding. Come to think of it you just remembered that your daughter is pushing you all to eat organic, and you got regular flour. Thinking that perhaps you can get away with the non-organic flour, you look around, and then see a recipe that uses honey rather than refined sugar. It looks like this recipe is actually harder to make, since they say honey browns really quickly. You vaguely remember that the stove runs hot, or is it cold? I'd probably burn regular pancakes! A sifter? Where's a sifter? Do we have a sifter? We have baking soda but not powder.
Let's just make ramen noodles.
How did this happen? The shopping list was certainly correct: you did need lemons, butter, eggs, and flour. But even the list wasn't specific enough (for example, you needed organic flour). Also, there was a lot of implied/assumed stuff that was actually really very important to making the dinner. This included technique, unstated requirements, and your skills.
Does this kind of thing happen in large systems development? Yes. Someone thinks you should make lemon pancakes, no one knows that's what you're making, and you wind up with ramen noodles. The objective (compelling vision) should be clear to everyone, and the important details should be worked out. In large systems development, a useful way to do this is use cases since they are more easily understood by a wider group of people. Also, it helps pull things together to illustrate the point of the requirements. Is there juice in your requirements?
Bookmark/Search this post with
Submitted by David Hobbs on 11 September 2009 - 2:39pm
A previous blog post covered some of the types of metrics to track progress in a migration. This blog post explores ensuring that quality is acceptable during the migration.
A Naturally Iterative Process
Whether you have a high degree of human intervention or not, you will be following a iterative process like the one illustrated below. Basically, you'll have a stream of sites/functionality/etc that you are migrating. As you migrate, you are checking the progress by some means or another. The worst case would be the internal team not checking at all but then getting feedback from actual site visitors after launching a part of your site. Even in that case, you will find mistakes and know what needs to be fixed in the next round.
Let's look at these steps. For illustration in this blog post, the concentration will be on quality of content, although of course the drive to progress on other migration metrics needs to be high quality as well.
The Stream
You have a choice in how to phase your project, and you should ground your phasing in moving toward your compelling site vision. By keeping the above process in mind, you can further optimize what you start migrating. Probably the largest issue you want to avoid is re-processing any content twice (that's the "re-apply as needed" box in the graph above), which is covered below in Short and Focused Iterations.
Apply Rules
The next step is to actually migrate content. Since you want this process to be as streamlined as possible, I list this simply as Apply Rules in the process. The key about rules is that, if defined correctly, you can have more consistent treatment (and results) of your content.
In an entirely manual process, you would hopefully have some sort of written checklist/process for those using the tools to migrate the content. The process might be something like: "a) indicate in site inventory that you are working on the page, b) turn into XHTML, c) add descriptive image descriptions, etc". At any rate, some rules would be followed during the actual migration.
In a more automated environment, the rules would be embedded in the scripts/tools used for migration. Note that not all scripts are created the same, and you should challenge your system integrator to creating scripts or configuring tools that can do things like scrape pages that might not be totally regular. Some questions to ask your system integrator include: a) will you be scraping pages, b) will links/images/documents be "managed" when migrated, c) how will references (links, documents, images, etc) be handled such they are consistent, and d) how is acceptable quality determined (see the next section for more)?
Find Mistakes
If you are applying rules to your migration, why a separate step in the process to check your work? One reason is simply that mistakes are found pretty much without anyone explicitly doing anything, so it's important to know what to do when mistakes are found (the following steps in the process). For example, you may have done a careful job migrating some content, only to have site visitors find issues with the content after it has already launched. Aside from the situation where mistakes are found "too late", some reasons to explicitly search for mistakes are: a) a different "pair of eyes" (whether a person or a separate script) can help find issues not found in the first go-around, b) it's often easier or lower-risk to check for errors (if automated) than to ensure correct migration, c) correcting mistakes earlier rather than later is more efficient (especially to avoid doing anything over), and d) you may not have the resources / backing to do specific testing later.
What to check when looking for mistakes? Although simply having people eyeball the content, a checklist would be helpful to make sure key elements are being checked. Note that the checks ideally cover what people, automated scripts, and the system has generated. Some example items to check: completeness (for instance, when checking a page as opposed to a piece of content, making sure that all parts of the page are fully formed vs. "no records found" errors), your standards / style guide, consistent layout (old, large tables not blowing out pages for example), persistent issues, and unnecessary code stripped out and only your styles used (so that it's not just about how the content looks now, but that when you change your CSS the look will change as well). Note that some of these tests are checking the content in various contexts and not just the content alone (since it may be far easier to discover content problems by looking at the pages that are to pull the content).
For a large migration, you probably will not be able to manually check every page. For any page, you have the choice of whether and how to check for mistakes, which broadly speaking fits into three possibilities:
- Manually checking
- Automatically checking
- Not checking
The decision on which of the three paths to take can be done by a variety of ways, including: by content type, by size of page/content, complexity of page, and importance to the compelling vision for your migration. If blocks of the content is highly regular, and manual checking seems to indicate that the migration works well for this content type, then automatic checks probably makes sense. For archival information formatting and small irregularities may not matter, not even checking it may be acceptable.
Change Rules
Whether it is checklists or automated scripts, the rules should be changed so that either the issue doesn't come up again (preferable) or at least there is an easy (hopefully automated) way to check. An unacceptable process is that mistakes from automated scripts are simply siphoned off into a bucket of items that need to be dealt with manually. Not only is this inefficient, but if you let that bucket of problem pages grow, you could inadvertently be blinding yourself to a major underlying issue that cannot be dealt with one by one.
Re-Apply As Needed
This is a key point. You could appear to be migrating along swimmingly, and then find an issue fairly late in the process. Do you go back and re-apply the new rules to the old content? Obviously you want to avoid either the impact or occurrence in the first place. To limit the impact, you could implement things in a way that it's easy to re-run automated scripts on content for tweaks. To limit the occurrence, short and focused iterations might help.
Short and Focused Iterations
There is no way to anticipate the issues you will encounter during the migration, but, especially since you want to avoid having to repeat any steps (a la "Re-Apply As Needed" above), short and focused iterations can help. By short and focused I mean:
- Trying to define what is acceptable quality up front
- Migrating a small amount of easy as well as very difficult content, representing as much as possible the full breadth of the type of content that will be moved
- Implement as much functionality (see other examples) as possible, to better expose issues earlier rather than later (see Why It's Difficult to Migrate)
- Check as thoroughly as possible as early as possible
The above list of suggestions concentrates on initial steps of the migration. Further into the migration, a key point is to make sure you understand the issues (meaning, you know what happened and how to fix it) you are encountering as early as possible, attempting to make sure that there are no deeper systemic issues.
Bookmark/Search this post with
Submitted by David Hobbs on 10 September 2009 - 9:36pm
So you have a bright shiny CMS configured, and you're ready for your internal users to begin hands-on CMS work. Do you just let the CMS vendor give their standard training and leave it at that? No. Training on the generic mechanics of the tool is important, but your site/organization is unique and needs specific training. Also, the out of the box training may cover items that actually are not important to your organization, adding unnecessary bulk to the training.
So, what do you need to train on?
This may sound obvious, but your training should focus on what your team needs to know in order to manage their content and/or sites. For example, if you look at Team Experience, Your Tools, and Your Web Standards, then you should train at the intersection of these items: training only on what the team needs to know, based on your use cases. For example, if a key group of users is going to be publishing content but not managing sites, navigation, etc, then this user group should ideally be trained only on how to do that task. Additionally, hopefully the tools and team experience further clarify what needs to be taught. After all, if your tool is enforcing some standards, then, aside from explaining why the enforcement is happening, training does not need to dive into those details. While ramping up for migration, you may consider training just on what the users need to do during the migration, which may be less than what they need to know for ongoing maintenance (this way, you don't confuse everyone with details they'll probably forget anyway, and then you can train on more specifics when they're about to use the new knowledge).
The following are some of the elements that should be considered for training.
The Mechanics of the CMS
It's true that the CMS users need to be able use your CMS, so they do have to be trained on these details. Assuming you've defined major use cases for your site (right?), you could concentrate your training on the use cases for the users you are training. If possible, hand out a cheat sheet so that your users will be able to conduct their business once they forget all the details (and hopefully they don't have to resort to the manual every time). At any rate, the user should only be taught what they need to complete their job, and in the context of the tasks that they complete. Also, this presupposes that the CMS has been configured in a way that facilitates the key use cases.
Writing for the Web and Basic HTML
Your users may already know basic HTML and how to write for the web, but often one of the objectives of a CMS migration is to decentralize publishing so you may have new folks. Yes, of course your new CMS has a phenomenal WYSIWYG editor (or so it appears -- I've never met a web-based editor I didn't end up not liking, hence me writing this blog post with a "fat client"), and hopefully you've been able to embed many of your standards in the editor (like the users can select styles but not fonts). That said, there are still some elements of good HTML that everyone should understand and be trained on. Also, if your CMS copies and pastes from Word, then you'll definitely need specific training on that (for instance, to indicate what to expect in the cutting and pasting). At any rate, depending on your users, the tool and how it was configured, and what you are accomplishing, you may need to teach some basics about writing for the web and basic HTML.
Your Web Site Standards
The tool will not be able to enforce all of your web site standards (although ideally standards are enforced as deeply in the system as possible). There will probably be some contention about the need for standards, so some background on that should be explained in the training. Aside from this important aspect, it's important to focus on the standards that the tool cannot enforce. Some will be items like writing for the web, covered above, but you may have other standards that need further training.
Tagging
Chances are, one of the reasons you are using a CMS is to re-use content. Also, sloppy tagging has such a major impact (and is so easy to happen) that training here is essential. The items that need to be covered are:
- Why tagging is important. An explanation (and hopefully "live" examples) of how tagging impacts where content appears, and how it affects search.
- How to use the tool to tag. Hopefully the tool doesn't hinder tagging.
- Rules (and rules of thumb) of how to tag. Do you tag to force content on certain pages, or only because it's actually about the topic or other attribute? How many values should be selected? What are the rules around the different values?
Of course, this depends on who is doing the tagging, and if you are going to have dedicated people tagging or if you will be doing automated tagging.
Workflow and Publishing Process
Some of the team may still be used to directly ftping files (or even using a lightweight CMS at home), but at any rate systems work (or are configured) differently so this is probably an essential part of the training. Obviously the workflow (clearly stating what the role is of everyone being trained) needs to be covered, but also items like caching need to be understood as these can mean frequent calls to the helpdesk if everyone doesn't know how it works.
Site-specific or Group-specific Information
This last point is easy to overlook but important for large complexes of sites. Different sites driven off the same platform might have slightly different flavors, requiring particular rules for each site. For example, the home page of major sites might be largely custom-managed, and hence needs consistency at the site or group level. Large sites should consider having their own style guide, and train one-on-one with new staff to the group in order to make sure the organization-wide training meshes with the realities of the group.
Bookmark/Search this post with
