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.
Once you are dealing with a big website with a large number of stakeholders, you have a challenge: how do you decide what functionality gets implemented on the site? If you run a small site, this question may seem completely ridiculous (and, if the question does seem silly then this blog post probably isn't for you). I've written before on product managing the CMS platform and website, but here I'll concentrate on one thing: why it doesn't matter if a group is willing to pay for the feature they want. This is always tough to deal with. Your internal clients will say things like "I don't understand. I have the money to pay for it, so of course you should implement this." Hopefully this blog post will help firm up you response.
So why doesn't it matter if a group is willing to pay for a feature?
1. They aren't really paying the full cost
Sure, you might estimate the total development cost correctly, but are they even paying for simple maintenance of the feature? Upgrades? More subtly, are they paying for the extra regression testing now needed for features that aren't even directly related? Or the extra troubleshooting required for even what turns out to be unrelated issues?
2. Consistency of web experience for, you know, the site visitor
Not that this always seems to matter much in internal discussions, but is this better for the site visitor? Sure, it might be a gee-whiz and exciting feature. But is it going to confuse the experience of the rest of the site? Even if conceptually you could make it consistent, will you have the time to implement it in a way that's consistent?
3. Not implemented in an extensible way
If a particular group is commissioning a new feature, chances are they are thinking about how it needs to work for their site. The cost they are willing to pay will reflect that. So then you implement something (perhaps partially under the guise that this could be a "pilot" of a new feature), and other teams want it. Well, now the cost has actually gone up since not only does the feature need to be implemented anew for the rest of the site, but the feature needs to be retrofitted into the site that initially got that feature.
4. Not implemented in a technically consistent way
If only a particular group is getting a new feature, then even the technical team will be tempted to take shortcuts to get it in as directly as possible. This may seem innocent since, hey, only this group cares about it. But actually adding any complexity to your system just adds to the frankenstein nature of your implementation. This means that as you are adding features you are just adding heft that may eventually grind your ability to add new features to a halt.
5. Limited resources anyway
Alas, you are only dealing with limited resources anyway. Maybe you can throw an external development team at the problem. But even if you are able to do that, what about the core team's coordination cost? This just means they won't be able to spend time on items that *all* groups want.
Obviously, sometimes special functionality needs to legitimately be developed. But consider the factors above before providing a new feature, and never just because a group is willing to "pay for it".
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.
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?
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 (
