Hobbs On Tech -- All Blog Posts

Site Launches: do as little as possible

hobbs — Thu, 05 Aug 2010 18:32:34 +0000

Being burned is probably the best way to learn things, and, having launched a lot of sites, I've also been burned a lot. So hopefully this little blog post can avoid some problems for others. Obviously if you have a small, new site, then your approach to launching a site can be very casual. But, especially if you are launching a prominent site, "flipping the switch" on a part of your site that's moved to a new platform, and / or need to launch a site precisely down to the minute, then you need to be a bit more coordinated.

If I were to give just one piece of advice: do as little as possible during the actual launch.

This sounds obvious, but I'm amazed at how much last minute tweaking teams are often assuming for their launch. Let's say you're shooting for a noon GMT site launch and the launch will be on a brand new platform that you've migrated to. The approach perhaps taken the most often? Lump everything into the final hours before the site is launched, and then end up needing to jettison functionality and / or quality at the very last minute.

Another approach would be to take steps such that the *only* thing you have to do is at noon GMT to change the DNS entry, so you're literally flipping one switch at the end. Again, this sounds completely obvious but is usually overlooked. What are some ways to pull this off? 1. Concentrate heavily on the tasks that can occur days before (for example: freeze development, run the search index, migrate the latest comments and content, change the DNS TTL, do final end-to-end testing). 2. Also you can focus on what tasks can be started hours before (final search indexing, migration, etc), perhaps by freezing new content/comments. Then you can do a final test just before launch, with all the content you're going to be starting up with.

What's a good way to see if you are in fact launching with a small to-do list? Conduct a thorough test of the site days before, and *rigorously* push on why certain features / content are not yet available for testing. This usually means something else needs to be done at the very end, and every last-minute task that needs to be completed increases your risk.

In summary:

Do as little as possible leading immediately up to launch
To confirm you're doing this, test end-to-end thoroughly days before, and think hard about anything not working yet.

-----

Need help coordinating a prominent site launch, or the migration leading up to the launch? Contact David Hobbs Consulting.

Content Migration Burden: It's Not Just Automated or Manual

hobbs — Mon, 12 Jul 2010 17:46:00 +0000

How much burden will each team face?

The content migration process is a bit more subtle than is obvious on the surface. Notably, it isn't just a decision of whether to automate or not, but how much burden the different teams will face. Sure, maybe a fifty page site should be migrated entirely manually, but for anything much larger there will be a blend of automation and manual intervention. Often the technical and non-technical teams don't really understand each other (or the migration process), so the technical team just says it will automate what it can and then hand it to the less technical teams to clean up. The technical team might do what amounts to an automated copy and paste with a twist of trivial cleanup using a tool like HTMLtidy. That's a bit like just kicking a bunch of rocks down the mountain for the people living below to deal with.

Problems with the simple two-step automation approach

Some problems with this technical-team-hands-off-to-other-teams approach:

Unplanned cost for nontechnical teams. By shifting the burden to the nontechnical teams (also typically known as The Client), these teams then have more work than they were probably anticipating. This approach gives no chance for effective estimation (see Why estimate? I'm not getting more resources for this site migration..
Lost opportunities. Often a lot more can be automated than is initially discussed (see Content Migration: What Can Be Automated and What Must Be Manual), and by implementing in this two-phase handoff approach these possibilities are easy to miss.
Lower quality. If all of this manual burden happens at the end of the process, then quality will probably start being tossed out the window.
Project slips. Obviously another outcome of this approach is project slips.

Dangerous Phrases

Here are some dangerous phrases to listen out for:

"We'll automate what we can". This is a signal that the technical team isn't engaging in a discussion about the migration but will bang out whatever they can quickly to ram the content into the new system.
"We looked at the content and it isn't regular enough to automate". If there are only ten content items that are in question, then move on and migration manually. If you have a large batch of content, you might want to dig in further. I once had a system integrator say that just because the phrase "Description" was used on some pages and "Overview" on others that it couldn't scrape out the content components. Wrong: regular doesn't mean identical and it is trivial to deal with these types of issues once identified.
"We'll turn it into XHTML and then you take it from there". Run. Fast. Turning into XHTML is trivial, and you probably need transformation as well. This is a sign that the technical team is not thinking creatively about migration.
"Since you'll have to edit the content anyway, you might as well clean up the HTML as well". Remember that editing and QA are different.
Anything ending in "and you clean up after that". The process should be iterative, not resulting in the editorial teams cleaning up unnecessarily.

A Better Planned Migration Approach

Instead of just stumbling into the migration process, I would recommend a more planned approach. Some ways of doing this (also see Web Site Migration Handbook):

Do a proof of concept and pilot
Iterate on the migration (so it isn't just two steps of "automating what we can" and then leaving it to the the content owners to clean up all sorts of problems)
Keep estimating the cost of the migration, including both technical and non-technical resources, to keep the dialog going about where the burden will fall
Ensure that all of these types of issues are talked about when initially working with your development shop, system integrator, or internal technical team to help determine an approach to migration instead of just hoping for the best later
define what acceptable quality is

-----------------

Need help defining your migration process so it will be a reasonable level of effort for everyone involved? Contact David Hobbs Consulting

The Fisherman and Web Strategy: the Allure of the Treasure Chest

hobbs — Thu, 01 Jul 2010 15:48:34 +0000

We all gasp at the treasures we see when they are already on shore. Sure, sometimes someone gets lucky, but usually the big web site successes we gawk at take a lot of hard work.

A story of two fisherman

Joe "the dreamer"

After watching a documentary about an explorer finding a hundred million dollar undersea bounty, Joe the weekend fisherman decides he wants to find an undersea treasure. The only equipment he has is a fishing rod, reel, and tackle. He starts by trying to snorkel to find a treasure, but after several weekends he finds nothing but seaweed. Then Joe goes out and buys a row boat, oars, and a long rope with a huge hook on it. Rowing out for several weekends in a row, he drops his rope down until it hits the bottom, rows to trawl the bottom, and then hauls the rope up. He finds nothing, and then decides to go back to the shore to fish from the beach like he used to.

Jake "the realist

Jake's friend the weekend fisherman is inspired by the same documentary, and thinks hard about how he can do something bigger. Although he's a motivated guy, he quickly realizes that his day job and other interests are going to get in the way of him getting funding for millions of dollars to find treasure like in the documentary, that might not pay off anyway. He considers getting a metal detector, but wants to be in the water. So he decides to fish for bigger fish, and buys a row boat, oars, and bigger fishing gear. The next weekend he goes out in his rowboat, and catches bigger fish.

The professional treasure hunters

On the same weekend, both Joe and Jake see a ship far from shore drop a little submarine into the water. Later that night, they hear on the evening news about that ship hauling a big treasure from the depths.

Fisherman	Before	After	Cost	Payoff

Joe "the dreamer"	little fish	nothing (didn't even catch any fish when trawling for treasure)	boat + gear + a lot of time	wasted time and no fish
Jake "the realist"	little fish	big fish	boat + gear + same time fishing as before	bigger fish
Commercial venture	big fish	treasure	huge resources	huge payoff

Don't be like Joe

So, are you like Joe? Fancy vision but no realistic way to achieve it? Then blaming your equipment when it doesn't work (and not seeing the big fish right below you)? Or like Jake, being inspired by something but riffing off it to achieve something bigger than you had before? Of course, if you are searching untold treasures, then by all means go for it, but make sure you think through a means of achieving it. Make sure you have the governance, technology, product management, sponsorship, content strategy, UI, IA, taxonomy, culture, money, staff, time, focus, and will to make your goal a reality. To stretch the analogy further, here are the elements needed to make a big project happen:

Hunting for undersea treasures	Web success

Defining your bounty	Defining your audience
Type of boat	Technology
Type of rod and tackle	Marketing and sales
Crew	Web team
Logistics	Project Management
Defining success	Defining success
Planning	Planning
Sponsor	Sponsor
Legal	Legal
Financial Management	Financial Management
Culture	Culture

For a small site, only the issues at the top matter. But for a large undertaking, the items toward the bottom are important for any large goals. Just like you probably will not find big treasure in the murky depths of the ocean without very specialized expertise, a large crew, specialized equipment, lots of planning and ongoing logistics, and managing sponsors, the same is true if trying to accomplish something big on the web.

--------------------------

Don't want to be like Joe? Need help creatively setting goals and the means of achieving them? Contact David Hobbs Consulting.

Web Product Management: CMS vs. Website Product Management

hobbs — Wed, 23 Jun 2010 12:51:39 +0000

Product management is crucial for the success of a website. For the purposes of this blog post, let's say web product (as opposed to project or program) management is considering your web presence as a whole to ensure a high quality and consistent experience for the users. That said there are two aspects to product management for the web: product managing the CMS implementation and managing the website itself (for now let's not consider those aspects of your web presence outside the website(s) you directly control). I've written on both the platform (Internal Content Management System Product Management) and website (see The Web Product Manager: Quality via Product Management) side of product management, but is there really a difference between the two? I would say the main consideration is that both roles need to be covered. At some organizations, one person may be able to play both and other (usually larger) organizations would require both sides.

Here are some of the responsibilities of both website product management and the product management of the CMS implementation:

Responsibility	Website Product Management	CMS Product Management

Overall consistency	Yes, of the site itself	Yes, of the implementation
Overall quality	Yes, of the site itself	Yes, of the implementation
Functionality	Quality from end user perspective, including not bloating the site	Quality from the technical perspective
Content	Overall content strategy, including training content contributors	Technology supports strategy and enforces standards as possible
Information Architecture	To ensure consistent implementation on site	Technology implemented to naturally enable official information architecture
Future-proofing	Watching trends to weave in new functionality	Implementing in a way that reasonably allows future functionality
Metrics	Web site metrics	Publishing and performance metrics
Users	Primarily web site users	Mostly CMS users, although web site user needs always take precedence

Both are needed for a successful large website, and need to be balanced. What happens if one of these is weak?

Weak Website Product Management

Bloated and unfocused site
Inconsistent site (if no enforcement and training)
Unhappy external users

Weak CMS Product Management

Implementation effort higher than ideal
Instable implementation, and difficult to maintain or add functionality to
Inconsistent site (if tool not aligned with standards)
Unhappy internal users

Obviously, both are interrelated. For example, in an unfocused website product management environment, the implementation could become unstable just because unreasonable and incoherent requests are demanded and delivered. That said, consider both sides of product management for your website. Are you now sufficiently covering both aspects?

Also see Lisa Welchman's definition of the web team including product management as well as Seth Gottlieb's Tips for Web Product Management.

-------------------------
Need help product managing your website or CMS implementation? Contact David Hobbs Consulting.

Developers, Don't Miss The Opportunity

hobbs — Tue, 22 Jun 2010 15:27:07 +0000

Give us the requirements first (reconsider!)

Having spent most of my professional life on the technical side of the world, I'm amazed at how often this statement arises:

They haven't told us the full requirements. Once the business users give us the requirements, we can get back to them with the level of effort.

Are you on the technical team? Before uttering the above words, first consider whether you are missing an important opportunity to shape the requirements. Are you on another team? Try to use the points in this blog post to encourage more of a dialog with developers.

Obviously the word "requirements" is not ideal in the first place (probably a blog post topic on its own). Some people get hung up on "a requirement is a requirement", but requirements are more subtle than that. By slightly shifting assumptions, you can often satisfy the underlying need with different written requirements. For example, I might say "I need an email when a user signs up for our newsletter". But what if I got the response "since we already all carry cellphones, and we have such a specialized newsletter that signups are rare, could we send it as a text instead -- also, you might not be aware that we're having problems with our email notification system so would rather add functionality to it"? I might say, sure that's fine. So if I stuck to the requirement as originally-stated it might take a long time and lead to greater instability, but by talking about it we wound up with a reasonable (perhaps better) solution that is more stable. Yes, if you're a stickler then you might say that the true requirement was notification and not email or text specifically, but the point is that talking about the requirements is more effective than lobbing written documents at each other. Obviously, this was a trivial example, but your requirements probably are not trivial so the ante is higher in moving toward strong requirements.

Why teams are tempted to use the give-us-the-full-requirements-first approach?

Some possible reasons:

Business users often do not understand their own requirements, and technical teams have been burned with shifting requirements once development starts
Being overwhelmed with requests, this maneouvre helps ensure that the business group is serious about these requirements
If the work will be farmed out by the technical team, having very clear up-front requirements will help in that process
Pure CYA (cover your ass), especially if relations between technical and other teams have significantly broken down

What are the problems of shifting the burden to the business side?

A few main issues:

Extended timeperiod from initial idea to implementation.
Limited opportunity to define ideal solution.
Increases adversorial relationship.

The first two issues above arise since there could be a very wide gap between the expectations of the business users and what can be implemented. Let's say the business users are imaging a castle, and write a huge document laying out the castle requirements including a moat. The technical team sees this and all they can work with is leather and wood, so they suggest a tee-pee with a pond. Obviously, if this is the start of the "negotiations" then it's going to be a long discussion (especially if the teams just lob documents at each other). Let's say that you eventually end up with a reasonable brick house (perhaps the masons on the tech team became available). Another subtle issue that arises in this type of arrangement: the business team still remembers that they wanted a castle and will compare the end result to the castle. The technical team will remember they first wanted to do a tee-pee and think anything about that is a favor. So the expectations really did not start things off on a good footing.

Collaborate instead

So what is a better approach? Collaborating from the start. From the technical perspective, you have the opporunity to shape the requirements in a useful direction. Some specific recommendations:

When first discussing requirements, always make it clear what elements of the request are easy and what is difficult. Moreover, consider how if the requirement changed slightly and the approach was a bit different, it would be far easier and more reliable to implement. In addition, the business team should consider the impacts to them if the functionality is implemented (for instance, the need for community manager to drive a new forum).
Have a process for product managing these change requests (including deciding what gets implemented and what does not), and have product management take the lead on bringing the teams together to deliver a high quality and consistent implementation.
Don't implement anything that will cause significant degradation of overall quality or reliability.
Document the pros/cons and decision process.

Agile methodologies help encourage a more collaborative approach, but regardless of the methodology you use consider working with the business users in developing your requirements.

-------------------------
Need help defining requirements, bringing business and technical teams together? Contact David Hobbs Consulting.

Why are HTML editors in CMSes?

hobbs — Mon, 14 Jun 2010 18:42:47 +0000

This may be a sensitive issue to many, especially those that like getting their hands deep into HTML, but should we even have HTML editors in CMSes?

Most users don't care about the HTML details -- they just want to make their content look nice. For instance, my last blog postincluded a table. Since I didn't have a quick and easy way of embedding a nice-looking table, I created a table in InDesign, took a screenshot, and then included that screenshot in the blog post. Yuck. Obviously not a good thing to do, but I didn't want to spend a few hours getting an HTML table looking half-decent. A couple days later the table was still bothering me enough that I did spend an hour or two (using help from Smashing Magazine) to put in a pretty nice-looking table into the blog post. But it was a one-time workaround and I don't have an especially clean way of doing this the next time I need a table. People do these sorts of workarounds in CMSes all the time. When this occurs on a big site, the extra work, inconsistency, quality and frustration multiplies quickly.

Just taking a table as an example, here's the process to creating and using table that would be great:

User indicates where they'd like to insert their table.
User creates the table content, giving headings to the table, perhaps merging some cells, adding columns and rows, highlighting some particular cells, and inputting content. Then publish.
The table then appears on the site with a nice-looking, consistent format -- let's say it has rounded corners.
User adds a column and row, and the rounded corners still appear.
Globally the CSS is changed in one place in one file and the highlighted cells are now longer yellow but blue. A similar change could be made for the rounded corners, cell padding, globally dropping Arial for Verdana, etc.

Notice a few key elements in this:

User doesn't have to know anything about HTML (hiding for instance the fact that the first and last column and first and last row have to be classed differently)
The table looks nice and will be consistent across the entire site without effort by the user
Styling changes can be made globally to all tables

When putting together requirements for selecting CMSes, I often hear about the need for the editor to completely control the HTML. But I think this is based on a broken model since most users are just dropping into HTML since the system isn't set up to easliy allow them to do what they need. Another reason this model is broken: it shifts the burden of consistency across content to training / documentation / content publisher when the system could both be providing consistency for the site visitor as well as easier use for the content publisher.

When looking at improving your system or selecting a new CMS, consider how common elements are published and whether deep HTML editing is needed for your content publishers. Obviously this will depend on your industry (for instance newspapers would want very streamlined publishing without HTML control) and how distributed your publishing is (this is more important for a large number of publishers), but make sure to think about the tradeoffs of deep control and ease of publishing.

Content Migration: What Can Be Automated and What Must Be Manual

hobbs — Wed, 02 Jun 2010 20:47:49 +0000

Understandably, teams often focus on what tools can provide for migration. On the flip side, many teams are too knee-jerk about getting a legion of people to migrate content by hand. The decision of automation or not is probably a bit more subtle than immediately obvious (it's not an either/or, and there are degrees of involvement needed by people), but one that should be considered carefully. That said, let's assume you have a team and the tools to do a lot of automation in your migration. In order to make sure that you have a successful migration, make sure to consider the things that cannot be automated. Here's a quick table listing some items that could be automated and those that cannot:

Migration Activity	Can By Automated?		Note
This is a revised HTML version of the table.		Click here for image of original table.
Turning into valid XHTML	Yes		Fairly trivial, but focus of some projects
Moving into new DB schema	Yes		Focus of many Tool X to Tool Y discussions
Placing content based on rules	Yes
Stripping out extraneous page info	Yes
Transforming to use new CSS	Yes
Scraping out structure from HTML	Yes		Systems Integrators often avoid
Dealing with links between content	Yes
Track Progress	Yes
Automatic tagging	Yes		Depends on domain and training
Training/designing/configuring tools		No	Automation isn't entirely free
QAing automation		No	Probably not 100% but checking required
Dealing with unusual cases		No
Defining new site vision		No	No unifying vision might mean loss of focus
Editorial changes		No	A lot of content will require editorial work
Internal communications		No	How communicate about changes?
Product Management		No	When issues raised, what will be fixed?
Training		No	How train people for new system?
Defining team		No
Defining site behavior		No	Contant won't be moved into vacuum
Content strategy		No
ROT cleanup		No	Analysis is aided by tools / decisions by ppl
Site governance		No
Defining taxonomy, IA, etc		No	Directly affects automation efforts

Content Migration is Interesting, Really!

hobbs — Tue, 01 Jun 2010 20:08:07 +0000

One of the underlying themes of content migration is that it's boring, or just a necessary evil. Worse, many just look at it as something that doesn't really need to be worried about, since at worst you could just hire a bunch of interns to cut and paste.

Perhaps you won't find content migration fun, but by looking at it through the lens might make it interesting enough for you to increase your chances of website implementation success. Here are some of the reasons you might think content migration is boring, and another way to look at it to make it more interesting:

Cutting and pasting 1) Searching for patterns and 2)Improving your content

Sure, if you are the one that's stuck with cutting and pasting into a new CMS then you've got a boring task ahead of you. But hopefully the migration can be flipped a bit so that it's not structured as a cutting and pasting exercise.

First, consider looking at your content for patterns in the content. For instance, perhaps all press releases entered between 2002 and 2006 were entered in a consistent manner and can also be dealt with (hopefully automatically) similarly. At any rate, by looking for patterns you can consider the migration at large rather than immediately devolving into looking at one piece of content after another. See more reasons for using rules.

Second, consider your broader content strategy, or, perhaps more likely, use your content migration has an opportunity to define your content strategy. Your overall content strategy can help you determine to do with your content, including what content is most important and requires careful editing rather than blind cutting and pasting.

By looking for patterns and considering your overall content strategy you can: a) look for automation opportunities and b) turn the exercise into one of Editing rather than simply copying and pasting (see a comparison between editing and QAing).

One-time exercise Setting up long term program

Migration is necessarily an event. You will probably iterate on the migration LINK, but there is a definitive beginning and end. That contributes to the boredom factor, but, similar to using the migration as an opportunity for content strategy, you can also use this as an opportunity to set up a longer-term program. You will need to set up a team, training, processes, product management, and other factors in your migration. By trying to look at as setting up your overall program than just what is needed for a single migration, the task takes on a more interesting color.

Unending Develop tracking metrics

Especially for large migrations, the entire undertaking can seem almost unending. By looking at it monolithically, this encourages the "well, we better just get started" approach. But I would encourage you to look at developing useful tracking metrics that will help make it feel a bit less insurmountable. Also, looking for patterns is related since you may track against those patterns, and patterns can also help you determine what level of quality is needed for different content.

Unimportant Critical to success

Most of the macho talk around a web site might be about things that lots of people have opinions on like design or technical buzzwords. Many of us can hold our own in these discussions, and much of the time these are important and interesting discussions. But the migration task is often viewed as something that can be dealt with later, or, as mentioned above, dealt with by interns at the last moment. Why migration planning is important? Here are three quick issues:

Migration can take much longer than expected, which means that from the project perspective there's a sudden slip at the end. Careful planning including a pilot can help reduce this risk.
Related to the above point, if you don't plan your migration carefully, you may realize systemic problems with your implementation. For instance, you may discover functionality problems with your site, and by dealing with them as a surprise at the end is more problematic.
Not planning effectively can mean problems persisting in your site that are difficult to correct later.

I'd like to make sure that as an industry we're planning and executing migrations better (one of the reasons for writing the Web Site Migration Handbook). Did this post help convince you that migrations are a bit more interesting? I'd love your comments, either on this blog or on Twitter at @jdavidhobbs.

Touchpoints During Content Migration: QA and Edit

hobbs — Fri, 14 May 2010 20:06:21 +0000

Content migration isn't just a technical undertaking. For example, you will have staffing impacts. In particular, people will need to touch at least some of the content being migrated. Regardless of the quality of any content migration automation, someone will need to QA the most critical pages of your site to ensure unintended issues arose during the migration. Furthermore, you may want to editorially change some of your content to hone the messaging of your site if you are also restructuring the site.

Broadly speaking, these are the steps that involve someone to touch content during a migration: Sort -> Place -> Edit -> QA. Sorting content is the task at the beginning of content migration planning where the disposition of the content is determined, which hopefully is done by defining rules/patterns rather than looking individually at content. So at this point team members need to decide what gets dropped, archived, moved over without change, or edited (see the website migration handbook for ideas on making that determination). Hopefully in the same pass as sorting, you can determine where content will be placed on the new site. Again, ideally this is done with rules rather than a one-off basis.

Actual changes to the content occur at the Edit and QA stages. Since different resources need to do each, the distinction is important.

Edit

Editing is where you are substantively changing the content. In other words, regardless of any technical issues, how does the content need to change? Is the focus of the site changing, requiring a different angle or style? Editing requires either someone with a writing / editorial background or a subject matter expert. For instance, if your site is about photography, then you will need a photography subject matter expert to write the introduction to an entirely new section on the latest technology. Note also that editing could occur either in the existing system or the system you are moving to.

QA

If editing is what the subject matter expert or writer needs to do, actually QAing the content is what someone with more traditional webmaster skills does. The purpose of the QA process is to ensure that the technical migration was successful. In other words, this is more of an HTML/CSS flavor of issues that require web knowledge to both catch and fix. QAing can only occur on the new system. The types of issues here are:

Special characters appearing unexpectedly
Aspects of the new template "blown out" (where content, images, or tables extend beyond the area they are meant to be within)
Strange wrapping of text (for instance in titles)
Graphical elements from the old site that do not appear correctly in the new site
Elements that have disappeared (it's useful to look at both side-by-side)
Elements that were prominent in the old content that have lost their prominence (for instance headers)

See "Ensuring Quality During Site Migration" for more on the iterative aspect of QAing.

When defining your content migration plan, you can attempt to isolate what needs to be Edited and what needs to be QA'd. Then this information can be used to figure out the staffing impact so you can make intelligent decisions.

Rules for Content Migration: Panning for Gold

hobbs — Thu, 08 Apr 2010 22:49:43 +0000

Moving content into a new CMS comes with many caveats (for example, is it even a good idea, and migrating to a CMS is far more than just moving content). However you slice it, moving to a new system is an important time to think about your content. Specifically, what content should move? Kristina Halvorson's Content Strategy for the Web lists two reasons to have content: a) it supports a key business objective and/or b) supports a user (or customer) in completing a task. So the Compelling Vision is important here (as always!). It's not just about what can be moved in, but filtering out the gold nuggets from the muck (see The Web Diet for more overall ideas on shedding bulk from your site).

OK, so how do you decide what to move? The most straightfoward method is to have a spreadsheet of content, basically an audit of your current content, and then line-by-line decide what moves over. This can work for smaller pools of content, but what if you have 10,000, 100,000, or more pieces of content? Even with a hundreds of pieces of content this can start being a bit unwieldy.

Having rules (like different types of sieves to leave behind the useful tidbits) for content migration are more helpful than one-off decisions for the following reasons:

Apply in the system on ongoing basis

Why go through the effort of your migration only to have the content go stale immediately? If you decide that press releases older then four years old should be dropped during the migration, then do you really want seven year old releases kicking around your system two years after launch. Similarly, if you decide that pages that are regulation-driven and over one year old should be reviewed, then don't you want that in your new system? Of course, there's a whole other area of governance around actually being able to enforce these rules on an ongoing basis, but perhaps during migration planning is a good time to discuss this.

Better justify drops

In a simple (no beauracracy) environment, justification is not really relevant. For instance, if I want to remove a page from this blog, I don't have to argue with anyone about it. But if you are operating in a large organization, you could wind up in endless discussions going nowhere by reviewing content items on a case-by-case basis (or, perhaps worse, just decide to throw everything into the new CMS again). That said, if you are dropping a piece of content because of a rule (any content of any type that has not been viewed more than ten times in the last year will be archived), it's much harder to argue with (of course, you would probably also need to come up with some sort of very tight exception policy).

More easily to agree first and then everyone do work separately

Related to the above comment, if you agree on the rules first, then you apply those rules and everyone can get cracking on whatever they have to do on the content. For example, if a rule states that a page needs to be updated because it mentions a particular highly negative incident, then the someone can start updating it rather than spending time talking about whether it needs to be updated. Related to this, having some rules in place would better fit into a web operations management framework so that existing teams could make high-impact decisions rather than the impossible task of getting mired in infinite details.

More easily identify disposition

Let's say you have a spreadsheet of 50,000 pieces of content. How do you start? You could just start at the top and work your way down, but how efficient will that be? If you have a rule like any content not updated in the last 8 years gets put into an archive site regardless of any other factors, then you can (assuming you have reliable dates) apply that rule and start working through the content in chunks like that. Note that the process of defining the rules probably means that you need to deep dive into your audit, but the point is that with rules in mind you will quickly see patterns that you can apply to quickly identify the disposition for different content.

Better move content

By looking for patterns, some commonalities may be relevant to deciding how to move content. For example, you may notice that content over a certain age used an old HTML template you forgot about, but that could be scraped easily. Or you may realize that your old working papers can just be moved in as-is rather than needing any manipulation.

Explain to end users if appropriate

If you have these rules in place, then it may in some cases be relevant to your end users. For example, if certain types of content go into an archive after a certain period, you can indicate this to your users. This also gives you a means for public feedback on your decisions.

Reapply rules once you realize you don't have the resources

While going through this process, hopefully you can also take some wild guesses at the effort it will take to deal with different types of content. If working in your content audit spreadsheet, you could always have a running table of the total editing effort. If the effort is high, then you can re-evaluate assumptions, change quality levels, and many other options. One option is to migrate in less. If you have applied rules, then you can tweak the rules and then see the impact on the projected effort. If you went in and did your analysis in a piecemeal manner, then you would now need to go through and have all those negotiations again about what's moving and not.

Hopefully this has convinced you to at least consider defining meaningful rules for defining your content migration. Please share your thoughts or experiences in the comments below.

From Vision to Use Cases for Selecting a CMS

hobbs — Mon, 15 Mar 2010 21:37:43 +0000

Good scenarios are difficult to develop (see Shock and Awe or Tightly Focused Requirements and Where's the juice in your requirements?). For a CMS selection they are essential since they will be the backbone for your comparisons between systems. By starting with your target vision and then stepping back to CMS priorities, the list of use cases you will develop, and then finally develop use cases, you will have a better chance of selecting a good CMS for you than starting with the details.

Why Use Cases are Easier for CMS Selections...

Requirements for CMS selections are easier than, for example, full system requirements since no system will be developed based on them. Specifically:

Only those use cases necessary to differentiate between CMSes is needed.
For each use case, only the level of detail necessary to differentiate between CMSes is needed.
Also, you have an opportunity during the selection process to better understand what your needs are (based on concrete demonstrations based on the scenarios, etc.)

Aside from general clarity to help guarantee high quality responses, you also do not want to overwhelm potential bidders (or make them think you don't know what you want or don't know what you are doing).

... And Why They're Harder

But the scenarios for CMS selections more difficult since:

They require discretion / prioritization (to decide what not to include).
A lot of long-standing issues (often/usually having nothing to do with the technology) will come to the fore. The temptation will be to gloss over these issues but the start of a CMS selection process is a good time to confront them.
Ideally you want broad buy-in to the requirements, but at the CMS selection phase things are probably a bit more abstract than stakeholders can easily comprehend.
There may be a rush to purchase a CMS, so one team is tempted to develop the requirements based on their perspective (perhaps only marketing, or only technical).
They are often developed without an overall vision for the new site.

How to Develop Use Cases

Given these issues, how should you proceed productively? The answer: starting at the top (the vision) and then drilling down until you have use cases targeted to the selection process:

Define vision
From the vision, define the CMS priorities
List just the titles of the scenarios that support the priorities
Write the use cases

Before diving into these steps, one key element is to get buy-in from stakeholders at each steps. By progressively getting more detailed you have the opportunity to get feedback as you proceed -- this way, you do not wind up spending a lot of effort on details before you really know what you're trying to accomplish.

Define Vision

Before getting into details, why are you even doing the migration? Even if it's mostly for back-end reasons (for example, you're current infrastructure can't scale to your imminent load), defining a compelling vision that everyone understands can ensure success of your migration. For large sites in particular, you may want to write an implementation strategy to ensure the vision is possible (along with pros/cons) so that you're not over-hyping the possibilities (for instance, it may be necessary to phase in your vision).

Define CMS Priorities

This particular article is dealing very specifically with the technology, but there's a good chance that success of your implementation will have more to do with non-technical issues than technical ones. That said, the point here is to develop good scenarios for a CMS selection, so the next step toward that goal is to define the CMS priorities (ideally these priorities can also be rank ordered) that support your vision.

List of Scenarios

Next, write out the list of scenarios that support the CMS. By defining your vision and priorities (and, for large sites, developed your implementation strategy), you will now be able to narrow down on what scenarios support those priorities.

Write the use cases

Finally, write out the use cases based on the list that supports the scenarios. Given your priorities, you will have a better idea of what details are important to include within the use cases.

In summary, start with the vision

By getting progressively more detailed, but starting with the question of why you are even attempting to migrate to a new CMS (which will be difficult regardless), you will hopefully get to focused requirements based on your actual needs.

Some related resources on other blogs (from 2006 to the present):

A Scenario-based Approach to Evaluating CMS Vendors (Tony Byrne of CMS Watch)
Top 10 mistake when selecting a CMS (James Robertson of Step Two Designs)
Selecting a CMS: Developing Usage Scenarios (Seth Gottlieb of Content Here)

The Metadata Sweet Spot

hobbs — Fri, 26 Feb 2010 14:33:54 +0000

The road to metadata quality hell is paved with good intentions. Spellbound by the possibilities a complex taxonomy (or just seeming like an interesting mental exercise in its own right), the team gets to work on a detailed taxonomy that could cover all the future needs of sophisticated searching / browsing. You have a problem when the complexity of your taxonomy outpaces functionality the site visitor sees. So if you have a five level deep taxonomy but your site visitors only ever see the first level, then chances are that only the top level is accurately tagged. Since the content contributors won't see any difference / gain, then why would they spend the extra time required?

Match automated functionality to taxonomy complexity

The metadata sweet spot is where the taxonomy complexity matches the automated functionality on your site. So for example the hobbsontech.com site is all tagged to the five stages of CMS migration, and this tagging is used throughout the site (on the home page, as tags with every blog post, etc). So the complexity matches the functionality, and I am compelled to tag correctly. In addition to the functionality, the match must also be in the pain level of bad tagging. So for example I originally structured this site differently so old posts do not have very useful metatadata. Since the pain level is relatively low, I haven't yet cleaned that old metadata (note also that this is a problem with free metadata tags without a large number of contributors). So if you bury some metadata-driven functionality that none of the content contributors care about, then the quality will also be low.

So what to do about this? Carefully consider any additional metadata complexity before adding it to your system. If at all possible, consider a way of increasing the visibility of the metadata through automated functionality on your site. The most direct way would be prominent functionality that the site visitor would see/use (and both the site visitor and content owners / site editors care about). Relying on administrative functionality (for example, ranking groups based on how much content is tagged to their detailed topic without showing this to site visitors) only would be more dangerous since it might encourage people to game the system.

For other related metadata posts, see:

As always on this blog, this post is most relevant for larger sites. Is your site large? Answer four questions to get a quick gauge.

Combating Your Biases: Achieving Site Success

hobbs — Fri, 12 Feb 2010 19:39:14 +0000

We naturally all have a bias of how we approach improving our web sites (Information Architects through an IA lens, programmers from a technical perspective, etc), but we should all occassionally be looking broadly at what is required for success of your web site. I would also advocate that someone (the product manager) should always be looking broadly at site success.

As always, I advocate starting with the vision of what you are attempting to do. This could be your vision for an upcoming site revamp/migration, or your long-term vision.

After you define your vision, you can then help to combat you and your team's biases by:

List out the various factors that will lead to meeting your vision.
Evaluating where you are, right now, against those factors.
Roughly determining how strong you need to be in each area.
Concentrate on the deltas, in particular those that have a wide gap.

So instead of diving into one particular area with a tactical view of your problems (for instance, a deep engagment improving the graphic design of a site), you can concentrate on those that will derive the most value. Also, hopefully this will focus discussions so that you are always going to just enough complexity that will meet your needs.

One way of representing this would be in a graph, highlighting a) the "ultimate" / maximum maturity / most complexity / most impressive / most Amazon-like / fantasy, b) current level, and c) the level required for your vision. See the example below, which highlights those areas where you are meeting/exceeding the capabilities toward your vision (in green) and those that require work (in red). In this example, your design level is exceeding what's required toward your goal (which would be good, but on the other hand might be an area where you could spend less). The widest gap in the example is around setting a shared vision, so perhaps should receive the most attention.

Shock and Awe or Tightly Focused Requirements

hobbs — Mon, 08 Feb 2010 18:06:59 +0000

Most written requirements / use cases are limp, not getting to the essence of the goals (see Where's the juice in your requirements?). Why does this happen? Often, since tough decisions are not being made.

Requirements should be focused and targeted to meet your goals. Since it is probably more painful to make changes later in the process (for instance, after implementation has started), making the tough decisions needed for focused requirements should be a priority.

Of course, some readers may argue that traditional written requirements are less effective than a more iterative, generative agile approach. I also like the iterative approach, and in fact it can aid in decision-making (for example, since working code is something that all stakeholders can respond to during the process). That said, sometimes requirements written in advance are needed, for example when selecting a Content Management System.

Some Types of Unfocused Requirements

These are some of the types of requirements documents I've seen that show a lack of decision making:

Shock and Awe

Some requirements documents obscure the real purpose of a system since they are so "impressive". These may inspire comments like "Wow, that requirements document is 100 pages and I barely understand any of it! That must have taken a lot of work! You're so smart!". The main problem here is that if stakeholders cannot understand the requirements, then there cannot be true agreement on them. Although these may impress some, they still probably lack much strength since it's hard to see the point.

Listless

Ambling requirements are also common, and these often result from requirements being gathered rather than analyzed and synthesized. Ambling requirements may contain flashes of important requirements, but are buried along with unimportant requirements or even inconsistent requirements. Listless requirements may also be too detailed in places.

Overly Generic

Some requirements documents read like "car must have a driving wheel and four wheels" rather than "sports car primarily used to race on a racetrack on the weekends". One is certainly a fact but doesn't help in, for example, selecting a car. The second one shows a bit more of the flavor of the true requirement.

One requirements documents can have both of the problems listed above, but they can all be helped by better decision-making.

How to Tell if Your Requirements Are Unfocused and What to Do About It

How to know if you haven't made the decisions you need:

You resist efforts to prioritize your requirements.
You are excited about a possible capability, but have not written the related requirements since the relevant decisions haven't been made.
An outsider reads the requirements and does not understand overall what you are trying to accomplish.

How to make the decisions you need:

Define a compelling vision. In other words, big picture what are you trying to accomplish?
Make sure the requirements are synthesizing. People do not always know what they want, so everyone's input on the requirements should be synthesized into a coherent whole. A good way to see if the requirements are coherent is to ask someone uninvolved (but aware of the general area you are writing requirements for) understands them quickly.
Even though it is hard, prioritize your requirements. Many resist the concept of prioritizing requirements, since a requirement is a "must have". Of course you don't always get everything you want, but, moreover, you want to make sure that your highest-priority requirements are easy and straightforward in your implementation. Perhaps a lower-level requirement could be satisfied with a bit of a hack.
Consider the purpose of your requirements. If you are selecting a CMS, then really the only requirements that matter are those that will differentiate one product from another (based on your objectives). If you are handing off development in bulk to another team, then the requirements need to be more exhaustive. The general point is to concentrate on the requirements that matter for your current task at hand.

Confusing Your Pilot / Beta Users Before Full Site Migration

hobbs — Tue, 22 Dec 2009 14:02:08 +0000

Your visitor winds up at a piloted section of your site, but the first link they click on goes right back to the old site. That would be a bit like playing a maze game where you suddenly roll into a hole and aren't playing in the game any more (but didn't know the rules or that you were playing a game). How do you deal with that and other linking issues when piloting a site? (Also see background on what/why to conduct pilots before full site migrations or all articles on pilots)

Web Site Visitor Confusion

What are some of the ways that pilot can be confusing for your site visitors? Here are some problems and suggestions for improvement:

Not Knowing Where the Pilot Begins and Ends

One of the keys to deciding what to pilot is choosing whether the site visitors will clearly understand where the pilot starts and ends. So before talking about any technical or implementation details, the selection should just make sense. For instance, if you have a clothing site then a possible piloted site would be the women's clothing store. This might make good sense to your set of users. Note that one of the reasons that you might be undertaking a new site is to consolidate different systems, so you may be piloting a new site that contains content from multiple sites. See the example diagram below, where some content from two subsites is being piloted in one site. Using the clothing example again, this could be where there are currently two separate sites that include all of your clothing, and you are eventually merging to one. You could pilot a women's site that will include content from both of the existing sites. At any rate, the key is that, even before considering the technical implementations, the site user should understand what is piloted and what is part of the old site.

Not Knowing When Leaving the Pilot Site

In addition, there are some ways you can implement the system to make it more obvious for the user whether they are on the piloted or existing site, including:

Indicating when leaving the piloted site. You may wish to implement a standard intermediate page that the user sees before leaving your piloted site (see #3 in the diagram below). At least that way the user has the opportunity to back up if they want to stay on the piloted site.
Clearly branding the piloted site. You also want to make sure that visually the piloted site is quite different from the existing site.

To Beta or In-Place Pilot

One question will be whether to just plain replace an existing subsite or to do a Beta that users can optionally try out. One advantage of a Beta is that you can have one entry point (the Beta home page) where you can explain to your users what the Beta is, including what the advantages of the new site will be (see #1 in the diagram below). If launching a subsite in place, then you also need to be ready for deep linking to your site. This can also be an advantage so you can do a live pilot of your rewriting rules, but a disadvantage is not being able to explain the new site as easily.

Unnecessary Linking to "Old" Site

If you blindly cut and paste content, you'll have a whole lot of links going straight back to your old site (like the ball dropping in the whole in the game above). This is because you probably will have hard links to your old site within the content. Some links will need to point to the existing site and others to the new site, depending on if the target content is moved into the pilot as well. If you are doing an in-place pilot instead of a Beta, then the old links should continue to work but you still may prefer to get the links "right" anyway (for example, if you want to use managed links that some CMSes offer).

As an example of unnecessary linking, let's say you have two pages B and C that will be piloted. If you just move the content without changing the links, you'll wind up on the old site when click from page B on the new site. Obviously you want to make sure to link from the piloted B page to the piloted C page (see #2 in the diagram below).

Example Linkages in a Pilot, when using a Beta

Pilot What? Deciding What Subsite to Pilot Before Full Site Implementation or CMS Migration

hobbs — Thu, 10 Dec 2009 19:06:40 +0000

Migrations can easily grind to a halt. By methodically launching a subsite as a pilot, and giving time to react to issues, you can partially mitigate against that risk. For more information on pilots, see The Pilot in a Site Redesign or Migration: A How-to Checklist, CMS Proof of Concept, Pilot, Migration, and How to Migrate Content into a CMS. Just to re-iterate one important point, it's not a pilot if you don't plan for a) time for real users to use the piloted subsite, and b) time to fix issues before moving on to subsequent subsites (see more).

How do you select what subsite to pilot?

The pilot needs to launch an actual subsite, but which one? There are two key factors:

Ensure the subsite will meet the objectives of the pilot
How easily the subsite can be teased out of the rest of the site

Before diving into some of these details, note that if you have a very large suite of sites that you will be implementing or migration then you may be more likely to launch a site as your pilot (rather than a subsite).

Ensure the subsite meets the objectives of the pilot

You may be tempted to pilot whatever is easy, but that would not really help you much as a pilot since you probably would not learn much of importance. One of the most important things to keep in mind is your pilot needs to test how well your compelling vision for the site will be met, so that you can quickly correct course if your vision is not being met. Including the compelling vision, the subsite you select should meet the objectives of a pilot:

Test key aspects of your compelling vision
Test virtually all aspects of the eventual migration:
- Automated migration
- Manual migration/editing/entry
- Deployment (making the site "live")
- Integration with other systems
- url rewriting
Feedback, with the intention of making changes prior to migration
- From actual web site visitors
- From the core redesign team (inevitably, the more "real" the system gets, the team will see more issues and uncover more miscommunications)
Estimate effort levels, which requires:
- representative content types (again, not just the "easy" ones)
- not just your super stars doing any manual migration, but a representation of actual users

Many subsites will probably be ruled out by the list. For instance, a subsite that just has one content type and only a few users would not work because a) you won't be getting a good estimate of the effort for moving all content types, and b) you might not get good feedback. Note that you may not be able to accomplish all of these objectives, but by thinking about them you can better choose a site and plan your pilot. On the objective of estimating effort levels, you will also need to establish a method of tracking people's effort (such as using some sort of automated reporting, or even a spreadsheet).

How easily can the subsite be teased out from the rest of the site

Broadly speaking, there are two ways of launching a pilot: a) replacing an existing subsite entirely, or b) as a stand-alone beta site (with a prominent link such as "Try the PuppyWeb Beta!"). Some advantages of replacing a site "in place" are that you are doing a deeper test, with all of your current users on a richer set of functionality. For instance, you can test url rewriting directly to see if your old links will still work (if that's what you are attempting). A stand-alone beta is easier to take down in case of emergency, and also is easier to extricate from the rest of the site. So which approach you take depends on your particular objectives and constraints.

Regardless, you will almost certainly have to think through linkages between the site that you are piloting and the rest of the site. A major factor in deciding on what subsite you pilot may be how easy it is to decouple / couple from the site. One helpful set to defining this is to draw a high-level architectural diagram, highlighting the interrelationships between systems and subsites. These are some of the factors to consider in how the piloted subsite will relate to the existing subsites:

Internal references between content within the subsite under consideration
References between your existing site and this subsite
Other linkages with organization-wide services and reporting, such as site-wide search, site-wide RSS feeds, and site-wide statistics.
References to the subsite from outside you site entirely (for example, Google references)
How identifiable the subsite will be to site visitors (will the delineation between piloted and "old" subsites be clear to the visitor?)

If a subsite already "stands alone", then it may be easier to migrate that. If an objective of your new overall site is better integration, then you may be able to highlight that in the pilot (by pulling content from both the "old" stand-alone site and content elsewhere).

Size Matters: Your Web Site Redesign or Migration

hobbs — Mon, 30 Nov 2009 14:43:55 +0000

Redesigning your site or migrating to a new CMS? The size of your site matters in how you plan for it. Do you have a complex site? Answer these four questions (don't worry if you don't know the exact numbers):

(push "click to edit")

Obviously, the calculator above is not comprehensive, but hopefully it gets to the how complex, broadly speaking, your site is. The questions attempt to use fairly objective measures. If the calculator shows your site as simple but you know that you have underlying complexities that the questions do not capture, then of course take that into account. For example, this does not cover extensive content re-use, which is a bit less objective to add in a simple calculator (re-use means different things to different people) but important to complexity.

A quick note: if your site is simple, then congratulations! This is something to be proud of, since you have a site that is relatively easy to manage and maintain at a high quality. That said, obviously some sites just are more complex than others, so if your site is complex then that is entirely valid as well. The point of this article is to point out that the complexity of your site should drive how you plan and run the migration. See The Web Diet for ideas on how to slim down your site.

Why Site Complexity Matters

The complexity of a site is often implied in discussions, but this can obscure core requirements. For example, the majority of CMS discussions are probably of the Joomla vs. Wordpress (or pick your other favorite) variety. Big picture, this is appropriate since most sites are simple. If your site is simple (like this Hobbs On Tech web site is), then by all means launch into these discussions. Or just pick the system that all your friends are using. That said, if you have a complex site, then you probably need to consider other platforms and also use a more rigorous CMS selection process. If over the weekend for a personal site you were talking about Drupal vs. Joomla, then you may be tempted to apply that same discussion to your company's site with hundreds of thousands of pieces of content in multiple languages. The discussion / approach will need to be different for a complex sites.

Similarly, the complexity of your site impacts your implementation approach. If you have a complex site, then a rigorous process is key. For a simple site, perhaps no real process is needed at all.

Process for the Complex, Large Site

Implementing a complex site requires the most planning and coordination. There are just more moving parts and relationships to manage. For example, widely communicating a compelling vision is key for a complex site, since there are more people to communicate with, coordinate, and set expectations with. Similarly, clearly planning (and, again communicating the plan) is essential since the project is naturally more risky. Aside from the obvious reason of there being more to design, any ambiguities can quickly explode into major issues. For example, if you do not define core functionality clearly (let's say how content is re-used), then it can be implemented differently by different developers for various sections of the site. This ends up being even more complexity to manage, and an albatross that can weigh down future enhancements. Also, management items such as defining the metrics to track migration are even more important since there are more people to align. The complex, large site should consider following all the steps in this interactive checklist.

Process for the Simple Site

Assuming it fits with the vision, one of the keys of a simple site is to make sure it stays simple. This may be as simple as just being very diligent about the simplicity, or, for slightly larger sites, putting some sort of process in place about how changes are made to the site. In general, the simple site can concentrate on the why and what of the site, and not the how (see more about the why, what, and how of implementations). That's the reason so much discussion is about what the site should look like (for example, designing the look of a site) and much less on how to implement. So a simple site still needs to define the design, functionality, and IA (although perhaps not as deeply), but probably does not need to define the metrics to track a migration or have a pilot (or communicate progress during the migration). Also, automation in the migration is much less important.

Process for the Medium-sized site

Deciding how to plan for a medium-sized site implementation is probably the least obvious. Obviously, the *why* (vision) and *what* (IA, design, functionality) has to be defined. The *how* is the most interesting. If you are attempting a bold new direction for your site (rather than more superficial changes), then you may need to follow all the items on this checklist. In particular, a change in direction may mean that a pilot is particularly important. The breadth of functionality / relationships will also drive whether defining metrics to track the migration is important (if your site has a lot of pages but no other complexity, then a simple tracking of pages may be sufficient). A major consideration is how many internal stakeholders you have, which will impact how carefully you have to communicate / train. This, along with how much is to be migrated, will also impact how much attention needs to be paid to the estimation of staff resources required.

How to Migrate Content into a CMS

hobbs — Fri, 13 Nov 2009 02:33:18 +0000

You're staring at a seemingly insurmountable pile of content that needs to be moved. For whatever reason, you are moving to a new content management system. How are you going to migrate this stuff? A natural conclusion is that you'll have to manually review, edit, and move content. That is understandably intimidating and would probably take a huge amount of time and effort. Moreover, especially for a large site, a manual approach has many other issues including lower quality due to inconsistency in decisions that the various editors make. Furthermore, even if you are going to be doing a lot of manual work, you should still look at the problem as a whole and break down the steps rather than just dealing with each piece of content in isolation.

So how can we turn this mess of content into something that is easier to deal with? In the following steps:

Divide the problem into manageable pieces
Take time to pilot and estimate
Re-assess based on your pilot, and migrate

Step 1. Divide content into manageable pieces: type, cut, automate

The first step is to break up your content into types. You may be lucky and your content is already neatly arranged or easy to identify. Or you may have work to be done to figure out your content types. You will need to do content analysis anyway to move into your CMS, so the first step in in the process is categorizing your content by type. To use a container ship analogy, instead of looking at the shipyard full of containers as a whole, start looking at each type of container separately.

The reason to break your content into types? You'll need to do that for a variety of reasons such as defining the metadata (which will help enable site behaviors) as well as define the editorial requirements on an ongoing basis. For the purposes of planning your migration, breaking into types will help you decide what to cut. You may feel that your press releases over five years old don't need to be moved, or the encyclopedia you tried that didn't work can be deleted.

One of the main take-away points here is that you want to define the rules for cutting content. For smaller sets of content, this may not be needed and evaluating / identifying from spreadsheets listing all content may work. But hopefully you'll be able to define rules that will allow you to not even have to take a second look at those that were cut. Defining rules may allow you to just cut wide swaths of content that isn't contributing value to your site. Some other ways of deciding to cut could include web analytics (cut anything that hasn't received page views in the last month), site section (not just the encyclopedia entries, but the whole encyclopedia site), metadata that already exists (the topic "parcheesi" doesn't interest anyone, so delete anything tagged to it in the current system), or even contributor/source (perhaps everything that intern entered three years ago can be safely deleted).

Next, you want to decide what you can automate. You've already decided what will be migrated, so now you need to decide what's going to be automatically moved. Automating isn't an either/or proposition, and in general you want to automate as much as possible. Again, the idea here is to define the rules about what will be automatically migrated and what will not. This will be useful in helping you estimate your effort and help prioritize. The biggest issue on what can be automatically migrated and not is the structure and "regularity" of the content. If you had a bunch of content that was already in a CMS, only referred to a common CSS stylesheet, was only in standard HTML, already had high quality metadata, and all the relationships between content was clearly defined, then you could migrate that easily. That's because in that example it's structured and regular. Chances are, your content is more interesting and varied (and hopefully less interesting once in the new system), so you will need to look at samples of your content and try to determine how regular and structured it is. If you can see patterns (which can be more art than science to find), then you hopefully can automate the migration of some portion of some/all content types.

After Step 1 of typing, and then finding rules for cutting and automating, you will have a more useful inventory of your content, with numbers like this:

Content Type	Original Count	Percent Cut	Percent Automated	Manual Count	Automated Count
Press Release	20,000	50%	50%	5,000	5,000
Article	100,000	20%	90%	8,000	72,000

Step 2. Take time to pilot and estimate

At this point you have some big numbers based on educated guesses, but you could still be wildly off on how many can be automated. At this point, take this one step further and try to estimate how long it will take to do the manual migration and automated migration. You might say that the press releases just need a small amount of manual massaging, so each one will take an hour on average. But perhaps those articles that you want to manually touch require actual rewriting, so will be four hours each. Using the numbers from the table above, this would mean the manual migration of the press releases is 5,000 * 1 hour = 5,000 hours and the effort for the articles would be 8,000 * 4 hours = 32,000 hours. This probably is more manual effort than you're willing to take, so you probably would cycle through Step 1 to see what other assumptions you might be able to change (for instance quality).

Let's say after your do your further analysis, you think a larger percentage of your content can be automatically migrated. Well, until the rubber hits the road, you won't really know if those assumptions are true. At this point, you should pilot an actual migration of a section of the site. Then you can actually see how much can be migrated and, by doing a sampling, you can discover how good the migration quality is (and potentially cycle through iterations to improve quality).

Step 3. Re-assess based on your pilot, and migrate

After the pilot it complete, it's time to re-assess where you're at. Did the automation yield the quality you were expecting? Are there ways of improving the quality through the automation rules? Are you going to need to jettison more content, or lesson the quality? You may decide that you need to do manual QA on a certain sampling of the automation on some content types, to confirm that the quality is working out over a large batch of content (this may also vary based on content type). See Why estimate? I'm not getting more resources for this site migration.

In sum, this is the overall process of migrating content:

After you have done the pilot and re-assessed, you should:

Have a good estimate of the effort it will take
Get a flavor for the types of issues you will be encountering
Have a way of breaking down the problem for the actual migration.

Also see the previous entry on ensuring quality during migration.

Be Careful!

This article jumps straight in the middle of migration planning, and assumes you've already taken care of other important planning, including:

Defining a compelling vision
Considered your content strategy
You have already conducted a proof of concept on your CMS
You aren't considering this a one-shot deal, but are looking at how to steward this content and the site over time

Remember that a migration is almost never just about content, but you need to consider relationships, teams, and tools.

A final note: you may feel a bit of a deer in headlights with the issue of whether something can be automated or not. I've heard some interesting excuses from systems integrators / development shops about why something cannot be automated, which may sound like valid reasons to you. Hopefully by conducting your pilots and estimates, you will have compelling reasons to automate as much as possible. As mentioned above, it can be a bit more art than science in seeing patterns and being able to apply them, and it certainly should go beyond throwing a tool like HTMLtidy at the problem.

Some People to Watch for Site Implementation Success

hobbs — Fri, 06 Nov 2009 20:51:48 +0000

This blog concentrates on web site implementation success, and I try to take a holistic view of that. Of course, we all have our biases, and my technical background probably comes through pretty strongly at times. That said, my primary concern is making sure that web sites get implemented well. In order to do so, I get inspiration from folks in various disciplines. For this blog post, I thought I would concentrate on some people in specialties that probably do not get enough focus:

Content Strategy: Kristina Halvorson (@khalvorson) of Brain Traffic and Jeff Macintyre (@jeffmacintyre) of Predicate are folks to watch on content strategy, which Kristina defines as "the practice of planning for content creation, delivery, and governance" (from the Content Strategy knol). Check out Kristina's book Content Strategy for the Web.
Product management: Scott Sehlhorst (@sehlhorst) writes the insightful Tyner Blain blog about product management in general, which I think is an area that does not get enough attention for web site management. Some recent favorite posts of mine are Product Manage Your Website and Modeling User Competency.
Design, with a focus of successful ongoing management: Paul Boag (@boagworld) comes at the problem of running large sites from a designer's background. See the Boagworld blog as well as the Website Owner's Manual. A recent favorite post is 10 Problems Your Content Management System Will Not Solve And How To Overcome Them.
Web Operations Management: Lisa Welchman (@lwelchman) of WelchmanPierpoint defined Web Operations Management, which "takes Web management out of the arena of daily management, mini-projects, and silo'd technology implementations and moves it into the more mature operations arena".

Of course, I missed many others in the above and related fields, but I wanted to highlight some of the key related fields and some of the folks behind them.

Are there others we should be watching when trying to implement successful web sites?

Priorities for Successful Web Site / CMS Implementation

hobbs — Tue, 03 Nov 2009 01:58:59 +0000

Tools get too much focus. I guess it's natural, and I also fall for the allure of a good tool discussion. But we should get a bit real on our spotlight on tools, and concentrate on what it takes to successfully implement or migrate a web site. I've written about how to migrate before, but not tried to describe the success factors in priority order. So what are the keys, in priority order, of a successful implementation?

Let's take the example of photography. Go to photography forums, and the discussions are about cameras, just like most of the discussions around web sites are tools ("Do you prefer Drupal or Joomla?"), or maybe the end result ("I love the new CNN redesign"). In photography, successful photos probably rely on something like the following, in priority order: 1) vision of the photographer, 2) timing and lighting, 3) format (medium format digital, 35mm digital, mobile phone camera), 4) support (tripod, steady hands, holding camera out the window of a moving car), 5) lens, and somewhere way far down in the list is the actual camera. Of course, it's not as much fun or sexy to talk about it this way, but the first items in the list are more important. Give an excellent photographer a pinhole camera with perfect pre-dawn glow, and you'll wind up with a better photo than a two year old in harsh noon lighting with the "best" camera on the planet.

So, what are the keys to a successful web site then? Here's my stab at the answer, in priority order:

1. Vision

Before implementing a site, you need a strong, widely communicated vision of why you are going through the effort. Otherwise, your whole endeavor could be misguided or just lack the direction needed to keep the whole project moving forward.

2. Support (the "tripod")

Can you actually implement and then maintain this thing? Do you have the governance, processes, and teams in place? During and in preparation for the migration, you need to train the relevant teams. Are you following a sound process for your implementation?

3. Product Management (the "lens")

You might have the vision and staff in place, but in practice during implementation (and on an ongoing basis), there are lots of seemingly-small details that need to be worked through that affect the overall quality. Note that this is not only about project management of delivering to originally-defined scope, but the continuous tweaks that need to be determined as the project goes forward. For an infrastructure product like a CMS, the tool must also be managed architecturally to ensure it is sustainable. Strong product management also means being able to clearly define the essential requirements, and concentrating on defining your requirements will also naturally help you in selecting your technology as well. See more on product management.

4. Class of tool (the "format")

You aren't going to build Amazon.com on Wordpress. If you need to build a website in the next hour, you're not going to build a new infrastructure from scratch but might use Drupal. More important than the specific tool is probably making sure you're in the right ballpark with the type of tool you are using.

5. The exact tool (the "camera")

I would suggest that the exact tool is not as important as the items above. That said, if you have strong product management clearly defining what needs to happen to meet the vision (and the processes to make this happen), then you'll more likely wind up with a strong tool. Another point: in the choice of whether to change tools or not, it's probably more important to first make sure you expend effort in the higher-priority areas. Of course, any of the above issues could derail a project, but I would argue that you can recover from the "wrong" tool if you are at least using the right class of tool. But you can't recover from a poor vision and improper support.

What do you think the priorities are for implementing a successful web site?