Pushing through ongoing changes on a website can be tough, whether it's because of inertia, other priorities, politics or other reasons. Although there is no single magic potion, one thing can help, and that's prominently posting your near-term work program (which should have short delivery cycles). Basically this would be listing out your upcoming work program, stating what you will be implementing when. This could be on your intranet, in an email newsletter, on the main CMS login screen, or some other place that all internal stakeholders could easily see.
Below are some of the advantages of boldly posting your work program on the wall.
Better engagement
As soon as you post what you plan on doing over the next few months, people are sure to provide their feedback. Since at first this feedback will probably be less coordinated than as you improve your processes, you probably will want to start with items that you are very confident in fixing and that have wide support. At any rate, you will increase engagement by clearly indicating what you plan on doing (and hence what will not be done as well).
More reasonable work program
By publicly posting the work program, everyone will hold you accountable for it. This is good all around, but specifically it will naturally force you to suggest a work program you are confident in. Also, since everyone will see the breadth of what you are doing (rather than simply the potentially-small sliver that they are concerned about), then all stakeholders will better understand why all of their requests may not be possible to resolve. See Product Managing Your CMS: Defining the Work Program for more on the inputs into your work program.
Better clarity
Also, you will need to be much more clear about exactly what it is you are saying you will do. Vagueness will burn everyone but especially the owner of the work program. People may think your "fix UI" meant far more than what you meant!
Higher confidence
Even if you end up not delivering 100%, the stakeholders will respect that you stood up to say what you were going to do, and then standing up again to update on what you did and did not accomplish. Of course, the highest confidence will be attained by consistently delivering on your promises, which then will also have the effect of less complaints on an ongoing basis.
More focus
It's easy to be vague when having distributed conversations with a wide range of stakeholders. But when you publicly state what you are doing, it will both force the person defining the work program to be more focused but also focus all the stakeholders on the near-term objectives.
This is something that can be done by event the smallest team, but is also highly relevant for large organizations.
The older your site, the more layers of content you have. This is similar to the layers of rock you see when driving through the mountains that have been blasted through for the highway. Some layers may be harder and others softer. On the editorial side, perhaps you had different writing style, editorial focus, editorial standards and general quality under different editors. On the technical side, perhaps ten years ago you were using tables for your formatting, then one division started using Flash extensively, and another group was frustrated by the controls in the CMS so used javascript to rewrite the pages. This information is probably important for your content inventory.
Some of the reasons to capture this:
Cutting content, either as a one-time or ongoing basis. The strata of content may be a key factor in your decisions.
Website transformation or migration. Any time your content needs to change to enable a transformation on your website, you need to understand what the transformation needs will be, and the different layers of content probably need to be transformed differently. To use a simple example, if a whole site section that was created five years ago is heavily Flash-based, then the transformation there may need to beg entirely different than for another layer.
Generally determining the quality. You may want to analyze your quality over time, perhaps even testing the impact of different approaches to content over time.
Before continuing on to ways of figuring out the layers, I wanted to point out why layers in particular is important rather than why you might just do counts of various aspects you want to test (these 10% have Flash, these 25% use tables for layout, etc). The primary reason is that it allows you to better look for patterns (for example, all the pages in this section use Flash and tables). Another reason to group by layers is that these are probably a way that internal stakeholders can wrap their heads around and make solid decisions.
Also, notice in the graphic above that if you look at the side you see slightly different layers than when you look from the front. So naturally what layers you see also depend on how you slice through your site. You may miss some important layers.
Figuring out your layers will depend on the specifics of your web presence, but here are some ways of figuring out layers:
Age. This one is relatively easy to get (although getting the originally-posted date can be a challenge), and, if you're going to slice on just one metric then this is a good one to start with.
Editor. Different editors may have dictated different content quality and focus.
Systems. From a technical perspecitive, the system (or original system if it's already been migrated once) can have a huge impact on the underlying technical content quality.
Chris Contakes, CTO of the Atlantic Media Company, led the technology migration of National Journal Group from a variety of platforms to Nstein in less than a year from concept to launch October last year. National Journal Group is an online and print publisher of in-depth non-partisan news and analysis covering politics, policy, and issues in Washington. National Journal Group’s flagship publications include National Journal Magazine, National Journal Daily, and The Hotline. The business embarked on an aggressive new digital strategy in 2010 to increase reach on the free side of the site and increase utility behind the paywall for subscribers. Executing the new strategy called for a complete overhaul of the technology infrastructure delivering National Journal content. Chris and I first met at a DC Web Content Mavens event and stayed loosely in touch throughout the migration. Before the National Journal Group Chris played the role of Manager of Content Management Systems for WashingtonPost.com. Below is an edited version of a conversation we had at one of my favorite Capitol Hill restaurants, The White Tiger.
Why did you migrate to a new platform? And how deep of a redesign from the end user’s perspective was needed to meet that vision?
Our in-house platform wasn't scalable and flexible enough to meet our needs as we transformed to a digital first publication. Our aggressive plan called for a launch in the fall which gave my team less than 5 months to migrate and build the new site. We decided to execute with a solution that did a lot of great things out of the box and would flex to serve our strategy.
We needed a system that could scale for growth, be flexible to integrate with a sophisticated paywall system, be able to support multichannel publishing (web, mobile, native iPhone / iPad (download) etc.). We also designed a sophisticated reader experience for visitors on the site. For example, one of the goals of the strategy called for no "dead ends". In other words, visitors should be able to access anything they can see and not see anything they are not entitled to (do not subscribe to) on web and mobile devices. Building this type of functionality into a native iPhone app required APIs for us to surface access control rules for content requests.
Going into the migration, one of your biggest challenges was adding more refined metadata to allow advanced browsing by your subscribers. How did you approach that issue?
During the demos, we were impressed by Nstein's text mining capabilities and were planning on using it for dynamic tagging. That said, since the editorial process already included tagging to publications (for instance, four editions of Hotline per day) and major topics (like National Security), the editorial team still tags manually to these primary channels. Nstein is automatically tagging to IPTC topics and surfacing these topics via the Solr search experience. During the migration, the old taxonomy values were mapped to the new ones. We used these rules to build migration scripts for the content.
How much of the migration was automated and how much was manual?
We have 30 years of editorial content including videos, articles, and podcasts. The 600,000 articles were automatically migrated using custom scripts. There were also data-driven portions of the site such as the Almanac of American Politics. In these cases the content stayed where it was with the new templates pulling in the existing data.
How much was dropped from the old site?
Most of the content was migrated, although some editorial features didn't migrate based on strategic decisions such as were the features were performing well and staffing decisions.
What was your biggest surprise?
The complexity of the 30 year archive was a surprise, with the content developed on changing systems with different writers and web producers over time. This meant that over time content having non-standard features (like iframes). We carefully babysitted the scripts, analyzing exceptions that the scripts reported. We knew there would be holes in some pages, but our objective was to move 98% without exceptions in time for launch. We then had a spreadsheet of the exceptions that the editorial team worked through in the weeks after the launch.
How did you deal with the aggressive timeline? We first met six months before your relaunch, and at that point you were still selecting the CMS. Since the president gave an interview mentioning the aggressive schedule, you were on the hook to deliver to it.
From the top down, our organization was focused on executing the strategy that we laid out earlier in the spring. The technical, editorial, and business teams were almost completely focused on the new website, with long workdays and weekends the norm leading up to the launch. The developers knew they were working on something impressive and remained focused on a successful launch. We also used some professional services from the Nstein team to assist where we could silo off development projects for extra bandwidth. We also did have to do some things that were not ideal. For example, the aggressive schedule meant we couldn’t spend a great deal of time on workflow design in the backend with the actual users that would be using the system for publishing. We relied on a lot of quick thinking and using workflows out of the box where we could with an understanding that we would refine in the future.
--------------------------
Are you a website owner with a migration success (or failure)? HobbsOnTech will be featuring interviews like this one to help provide a repository of experiences that others can draw upon. Please contact us if you would like to participate.
Content inventories are often considered just long lists of content. In fact, the top Google.com search result on "content inventory" is still the 2002 Adaptive Path article calling them "a mind-numbingly detailed odyssey"). But sites now are often getting way too complex (and big) to plod through every entry.
Many web presences have multiple sites or perhaps subsites or major sections. A multinational consumer product company has sites per country and / or product. Advocacy organizations may have a site per initiative, and news sites will also be broken down into primary sections like Sports.
So instead of a mind-numbing list, your content inventory could be grouped to come up with site inventories like this:
Subsite
Pages
New Template
Popularity
Percentage of pages using most recent corporate-approved Dreamweaver template
Percentage of pages that have received less than five pageviews in the last month
Sports
5000
100%
50%
Celebrity
1000
90%
50%
Europe
1000
90%
90%
World
2000
10%
90%
Politics
3000
50%
50%
Weather
6000
100%
10%
You'll notice that this type of report tells you a lot of information that probably would not be obvious when poking around a laundry list content inventory. For example, you see:
Which sites have a high percentage of unpopular content that are also small and on an old template -- potentially the entire subsite could be dropped for example
Which sites are completely using your newest template -- these could potentially be the first to migrate in a migration project
What sites are large and in the new template but with a lot of unpopular content -- these may be ripe for a new publishing strategy
Part of the point of the site inventory is that it is combining information from multiple sources (the above example table lists some possibilities but there are many more). Obviously, you could look at your analytics to just see the total page views for a site, or even the % of pages on a site that have under a threshold of pageviews per month. But it gets much more interesting when you combine the information, especially when you are considering phasing changes to your site. For example, you could migrate all sites that are 100% in the new template first, then in the next phase move those that have 90%+ in the new template.
A site inventory view into your content inventory of course isn't the only view you need to take. You need to look specifically at high-value content, and may need to slice and dice the results in different ways (such as by content type). But for complex rollout planning or other broad analysis, especially for very large sites which an organization doesn't have a solid handle on, site inventories can help drive decisions.
Note that the site inventory can just be derived from a larger content inventory. For example, if your content inventory has less than a million items, then you can use Excel pivot to aggregate the information (and other tools could be used for larger sets).
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).
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.
