Implement

Product managing your CMS: defining the work program

Any CMS implementation with a large number of stakeholders will generate far more requests than could ever be implemented.  So how do you determine what gets onto the work program and then implemented? 

There are several streams where potential features could get added to the system:

• User requests (either internal or external)
• Stability / security
• Performance / scalability
• Hardware / infrastructure
• Long range requirements

So even an important user request may not make it onto your near term work program if, for example, there is a severe stability issue that needs to be addressed quickly.  So there is something of an air gap between the requests coming in and what winds up on the work program.  This is one of the most important roles of the product manager, and the product manager needs to consider the following factors.

Backend needs

As mentioned above, key security, scalability, performance, or manageability issues may trump any other requests.  Notably, these may be items that your key stakeholders may not be aware of, much less actually requesting them.

Batching

Your near-term work program needs to be consistent, meaningfully grouping changes.  This is both for communications and technical reasons.  From a communications perspective, if the items being addressed are consistent then everyone can quickly understand what's happenning.  From a technical perspective, if you need to completely rewrite a subsystem to address and issue then it might make sense to address many of the issues with that subsystem at once. 

Resource constraints

Obviously you need to have the resources to implement your work program.  This is both for a raw number of hours as well as balancing key resources.  For instance, if your DBA is required for many requests then you may be able to only do some DBA-limited requests at once.

Popularity

Of course, the popularity of a request is very important, but, again, not the only factor).  All other factors being equal, a more popular item should be placed on the work program before others.  In practice, it may make sense to delay your top-requested feature in order to address the next three (for instance if the next three could be implemented in the same effort as the first).

Note two factors that are NOT listed as factors:

• a group being willing to pay for certain functionality (see the previous blog post You're Willing to Pay for That Feature?  So What?)
• the length of time that an issue has been discussed

In the end, the product manager must be able to justify the work progrm to the stakeholders.  Although clearly more of an art than a science, the factors (and non-factors) should help in forming that solid work program. 

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

Need help managing your CMS implementation as a product? Contact David Hobbs Consulting.

Topic Pages: Fruit Can Be Different Colors

Many sites are largely organized around topics (as oppossed to, say, the org chart or products).  But there are plenty of nuances to having successful topics pages, from dealing with political issues (when should a new topic page be created) to functionality options (how should topics pages be managed) to the metadata concerns.  If creating automated listings on topics pages, consider this:

You can only have automatically-pulled topics listings if there is a one-to-one or many-to-one relationship from your source metadata tags to your target groupings.

This probably sounds a bit too academic, so let's look at this in concrete terms.  Let's consider the case where you have a bunch of articles tagged to either broccoli, apple, or orange.  If you wanted to have a vegetable topic page and a fruit topic page, then this would work fine.  This is because you have a one-to-one mapping from broccoli to vegetable (broccoli is always a vegetable), and a many-to-one mapping of apple and orange to fruit (both apple and orange always map to fruit and nothing else).  That said, you cannot have red and green topic pages based on the existing tagging.  Broccoli is always green, so if the only tags you had were to broccoli then you would be fine.  But the apple tagging is the problem: an apple can be either green or red.  Obviously, you could introduce a new color tag, but if you had a large number of existing pieces of content then you would have a large amount of retagging to do. 

This may be obvious when looking at three tags and a handful of possible topics pages.  But when looking at larger repositories and the possibility of creating topic pages with some automated pulls, consider the mappings to ensure you end up with relevant topics pages.

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

Need help setting up or fixing the processes, functionality, metadata, or other aspects of creating topics pages on your site?  Contact David Hobbs Consulting.

Should you automate your migration?

Automation is a worthy goal, and I'm always looking for ways to automate migration where possible.  That said, obviously there's a tradeoff between automation and manual migration.  For instance, if you have a site of ten pages then don't even waste your time talking about automation and buckle down to copy and paste into the new system (or just create the new content from scratch).  At the same time, if you have a site with 500,000 pages that you want to keep, then you probably want to spend a lot of time talking about automation.  So how do you know whether to pack up the pickup truck and move yourself, and when is it time to try a more sophisticated approach?  The following should help in your decision.

Evaluating whether to automate

What are some of the factors in deciding whether to automate or not?

Commonality

How consistent is the content you will be moving in?  This one can be easy to ask but difficult to answer.  Much of the discussion of a migration is looking for patterns, so this isn't literally about whether 80% of the content on a current site is driven by the same template (although that helps).  For example, if your current site is not in a CMS but still every page consistently uses H1, H2, strong, and em tags then you may be able to scrape out the information you need.

Structure

The structure of the content / pages on the source and target system are also crucial, since this will determine how much transformation is required (and, notably, whether people will need to edit to get there).  In the example above with the content  that has common usage of H1, H2, and some other tags, that commonality is useful only if it maps usefully to the target structure.  For instance, if the target system is highly structured but the source system is not, even if it's common / consistent then it may not help you much in automating your migration.

Editing requirements

When considering the vision of your site after migration, you may necessarily need to modify a swath of content purely for  editorial reasons.  Obviously, this is a big argument for manual work, although it may just mean a modification of the process such that initial migration is done in an automated fashion but regular editorial work is done after initial technical migration (or other process changes may be needed).

Staffing

If you have a large and distributed publishing community, then even a large number of pages may be able to moved fairly quickly.  That said, this does necessitate a fairly polished publishing system earlier in the process.

Raw count

Obviously, the more content you have the more likely automation will make sense.  But there's one very important nuance here: it's the count of *similar* content that matters.  In other words, if you have 10,000 pages but 100 groups is each managing completing different sets of 100 pages each, then it may make sense for each group to manually move their content!

Advantages of automation

Iteration

Almost by definition, automation means repeating runs of migration until you work out the kinks in your automation rules.  This is completely different with the manual process, where people are much less likely to go through all the content again to make an improvement only realized later in the process.

Cost savings with consistent content

This is probably the key reason organizations look to automation.  With the right level of consistency, source and target structure, and number of content items to be moved, automation can bring cost savings.

Consistency across large amount of content

Related to the point on iteration above, it's easier to have a consistent level of quality across a large amount of content, since you do not have to train a large number of users that might be treating content differently.

More likely to see patterns that can be applied on an ongoing basis

The most interesting aspect of a migration is searching for patterns, and many of these patterns can be used on an ongoing basis. 

Less dependency on the publishing process being perfected

One of the key aspects of CMS acceptance is the publishing experience for content providers and site owners.  With automated migration, this publishing process does not need to be as perfected before migration starts.

Advantages of manual

DIY

You can start as soon as editing tools are in place.  Also, there's no need to engage with the technical team.

Budgeting

It may be easier to get the budgeting in place for manual migration than for an automated migration project, especially if you already have access to a pool of content contributors that could work on the project.

Built in editing

Especially for a smaller set of content, you can ensure  that human editing of the existing content occurs during the migration (although for larger migrations getting consistent quality may be difficult).

Built in QA

If someone is staring at the content during migration, then nominally they have a chance to QA whether the migrated content looks good.  Note that this means that the output templates need to be complete for a solid QA during migration.  Also, this works best when the same people who are migrating the content also own the content, which may not be true.

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

Want a worksheet to help in your decision of manual vs. automated?  Subscribe to Ten Weeks to a Better Migration for weekly action-oritented information and excercises to improve your migration effort.