WelchmanPierpoint - David Hobbs

Why estimate? I'm not getting more resources for this site migration.

David Hobbs — Wed, 15 Jul 2009 05:44:09 -0700

We recommend that clients do a simple back-of-the-envelope calculation to determine if they have the resources they need for a site migration. One response we've heard more than once goes something like "Why estimate? I'm not getting more resources for this migration."

Example rough calculation: Let's say that you discover or estimate that on average a person can migrate 4 pieces of your content a day. If you have 20 people working on the task then that's 80 pieces of content a day. If you have 80,000 pieces of content, then that's going to take 1,000 days.

Even if we assume that you cannot bring in more resources, these are some of the actions you can consider if you discover you don't have the resources you need:

Migrate less. Similar to moving from one house to another, a migration can be a good time to get rid of old (or redundant or trivial content). If you see you don't have time to move everything, then you could decide to not move sections of the site, certain content types, certain ages, or content that is viewed very infrequently (or a combination of the above). Also see The Web Diet: How To Simplify Your Web Site.
Migrate at lower quality. This one sounds crude, but it could be that some content (probably the same stuff that was being considered not to be moved at all) could be moved with less quality than what you were hoping for (for instance, maybe it has some tables that aren't sized correctly or other formatting that's a bit messed up). Obviously this probably only makes sense when migrating a larger site. Also, it's better to do this proactively in a controlled manner than in an uncontrolled manner in the middle of a migration (so that, if unplanned, you may inadvertantly migrate important content at lower quality).
Automate more. This can be related to the previous bullet, since you may discover that you can automate large swaths of content if you're willing to deal with a bit lower quality. That said, a knee-jerk reaction (especially from the technical team / systems integrator) may be that it's "not possible" or too hard. If you have the facts of the resources needed for manual migration, you may discover that it actually is worth it to dig a little deeper to determine more of what can be automated. A common complaint will be that the content isn't consistent enough, but there is often more consistency / patterns than immediately obvious, especially if you're willing to scrape pages in creative ways. At any rate, even if you are attempting to migrate and the technical team provides reports of what cannot be migrated, I would recommend digging deeper if the same issue is happening frequently.
QA less for some content. It may be that key pages need to be manually reviewed, but this doesn't necessarily mean that all pages need this treatment.
Phase. In general, a pilot can help you work out the kinks in your processes before the masses start using your new CMS. Also, a pilot can help you better gauge how long things will take, so you can re-run your estimates. After pilot, if you know you don't have the resources you need for the entire migration to occur in the needed timeframe, you can phase them more confidently based on your estimates.
Improve training or the content entry tool. You may discover that users are getting tripped up on particular steps of the content entry. Sometimes this could be improved by training, or you may find that rearranging the content entry screens would vastly speed up the task.
Set expectations. Communications during a migration is key, and easy to overlook in the heat of a complex migration. One of the main steps is to create, communicate, and re-enforce a compelling vision for the migration. In addition to that, if you discover that the migration will take longer than desired, you can *communicate* about it. Hopefully that compelling vision is strong enough that people will be ok with a longer migration time if that's just the fact.

The bottom line is to be realistic about your planning, so that your reasonable estimates align with what you are attempting.

A brief note on estimating: as the example above illustrates, you want to start by estimating the number of content items someone can migrate in a day. Depending on the complexity of the migration, you may want to dig one layer deeper to break this down a bit more by type of resource (for example, staff, intern, outsourced) or content type (simple flat page vs. complicated structured page vs. old crusty page with bad HTML). Also, if you are planning on using non-staff resources, then be sure to consider the extra documentation, training, communication, coordination, and QA time that may be required of folks that don't have all the implied context of your site and organization that staff have (an upcoming blog post will probably cover this in more detail).

Also, see Large Web Site Migration Checklist and Five Suggestions for a Successful CMS Migration. The topic of migration is firmly in the Execution layer of Web Operations Management, so please also see our definitions of Web Strategy and Web Governance which need to be in place for a successful migration.

Large Web Site Migration Checklist

David Hobbs — Thu, 09 Jul 2009 06:19:27 -0700

How do you even get started in your planning for a large Web Site migration? Of course, you want to have strong Web Strategy, Web Governance, and Web Team in place. Probably another useful step is to just get a feel for the overall scope of a migration, before diving into any particular details (or just starting without planning). Perhaps this one page checklist will help your planning by providing some ideas of the scope of migration planning (click to see larger image appropriate for viewing/printing):

Some key take-aways here are that: a) it isn't just about the technology (but executive sponsorship, resource needs, and financial support needs to be secured), b) it's impossible to fully anticipate issues so pilot, c) communications and creating a compelling vision (internally and externally) is necessary, especially to help get you through the inevitable hiccups, and d) track migration progress, preferably automatically versus manual self-reporting, based on metrics defined prior to the migration. Also see the previous post Five Suggestions for a Successful CMS Migration.

As always, your comments would be appreciated.

Corporate Sites and Back Channel Communication

David Hobbs — Wed, 01 Jul 2009 07:00:07 -0700

Definition of back channel communication: "'Grapevine' or informal communications that travels parallel to (and sometimes ahead of) official channels in an organization or society" from BusinessDictionary.com.

Of course, the "real work" of organizations is usually done informally, so unofficial communication is extremely important. That said, if you run a large Web site, you have probably encountered these types of internal issues:

Multiple meetings re-hashing the same thing. This can happen even without back channel communications by people not attending "decision-making" meetings, but it becomes worse when those that did not attend talk and get energized / momentum behind alternative decisions. Of course, people getting energized and coming up with creative solutions to problems is important, but channeling that into an efficient fashion is important.
Groups not understanding what is happening with the Web and the tools, resulting in unproductive and negative conversations. Obviously, this can lead to negativity when people's expectations (which may have little grounding if communications are poor) are not met.
People feeling that some groups are receiving unfair treatment (for instance, loud and/or annoying internal users getting undue attention). If some groups get special attention from the implementation teams, then not only will other groups get upset but you may be doing your Web site a disservice.

These types of issues arise from unproductive back channel communications. Again, this is for large sites in organizations that are probably already bureaucratic. If you work somewhere that these aren't issues, then count yourself lucky and maybe this blog post will seem ridiculous. If you do have issues like those above, then perhaps setting up these frameworks / processes will help:

effective Web Strategy and Web Governance. One result of setting up effective Web Strategy and Web Governance will be a clear set of Policies and Standards that drive your Web site. This will mean that, regardless of whether it's formal decision-making or people creatively and independently coming up with useful solutions, the discussion will be within the realm of what makes sense for the organization.
a clear communications approach. One of the reasons people have negative discussions is that they just don't know what's going on. Often, this is not their fault. So make sure you have a process in place about how to communicate about your Web presence (what changes are upcoming, how decisions were made, what was not done, any performance issue updates, how to get help, etc).
a process for people to effectively provide their feedback. Good ideas can come from anywhere, so you should have a way for anyone to make suggestions for improvement. Note that this could be feedback on policies and standards, but also more detailed decisions such as how the CMS needs to be implemented.
rules for how decisions are made. If people are going to be providing suggestions, then they need to understand how that input will be considered. For example, if ultimate decisions are made by a committee that votes, then rules such as who gets to vote, how votes happen, what is a quorum, etc, need to be clear to everyone. The decision-making process would normally be different (and with different people) for policies, standards, and more specific areas such as tool definition. At any rate, having this type of clarity helps avoid re-hashing decisions at multiple meetings.

In summary, if you suffer from negative and inefficient, internal back channel communications around your Web presence, then consider setting up effective Web Strategy and Web Governance and defining communications, internal user feedback approach, and decision-making processes.

Rules, Games and Web Jobs

David Hobbs — Thu, 28 May 2009 05:55:56 -0700

For a few years, I hosted a fun annual scavenger hunt in the Adams Morgan / Dupont Circle area of Washington, DC. Before everyone raced out with the clue list, I would go over the rules -- everyone would roll their eyes and groan at this point. A few hours later, after everyone got back with ginko leaves, strangers' phone numbers, religious group brochures, and obscure cooking ingredients, there would be quite vocal disputes over who got points for what. Of course, at that point, the rules would help move things along so that the prizes could be given out.

Games in general are probably the best example of where rules are, by definition, about having fun. How would monopoly or poker work without rules? So why is there often resistance to rules / standards on Web sites, when they are, most simply, about ensuring your site is consistent with the mission of your Web site / organization?

Here's a major reason for resistance to standards for an organization's Web presence, even if it isn't usually explicitly stated: peoples' jobs will change. Even if it did not help the organization's mission, people were used to creating sites from absolute scratch, picking colors, layout, etc. It's kind of like people were used to creating games (and hence the rules) and are now just being asked to play a game that someone else created.

So what can you do for those whose jobs will change?

Make sure you include the people that have been designing sites / pages / applications from the ground up in designing your standards and templates. By being involved, these folks can be setting the standards that the entire organization will be using. So, they are trading off complete control over a smaller set of pages for some control over all pages.
Clearly articulate why you are standardizing. By having top management buy into Web Guiding Principles and then creating Web Policies, everyone will understand and be aligned to the overall objectives. Also, we recommend that all standards include a rationale to defend the reasoning behind a standard.
Set up strict criteria for breaking out of your standards. Especially for folks that have been used to creating their own pages, they may quickly do whatever they can to break out of the standards you develop. Obviously you want to create the system so that it is easier to "do the right thing" (for the majority of users, this just means the system will be easier to use), but you will also want to create rules so that everyone knows when it is appropriate to break out of the standards (and how to request that).
Train staff and define roles. Instead of a wide range of people playing a graphic designer, most staff will be providing content. Instead of everyone designing information architecture, they will be spending time to better tag their content. This probably involves training on how to do that better. For those that are the graphic designers or other specialized Web roles, consider what new roles they might be able to play if they aren't, for example, designing separate Web pages (maybe now, in addition to defining standards, they need to work with the technical teams to implement templates that work for a wide range of pages).

In addition, there are advantages to having standards for those who were not previously working on the Web. You'll want to emphasize that those who used to be unable to directly publish on the Web will now be able to. So those that have subject matter expertise outside of the Web can concentrate on their expertise and getting their message more directly onto the Web.

Since standards need to be in place to ensure success of your Web site, it's important to consider the designers and programmers that are currently accustomed to designing pages/applications/sites. In particular, make sure to include them in the standards-making bodies, clearly state why standardization is important, don't make it easy to break out, and train and define roles for impacted staff.

Non-technical Input on Technical Standards and Requirements

David Hobbs — Mon, 13 Apr 2009 13:11:41 -0700

Many technical groups within organizations feel that they own all things technical and therefore should define requirements (for example, CMS requirements) and technical standards (for example, the Web Tools and Applications standards team that we recommend groups have). On the one hand, I totally sympathize with these groups (I come from the technical side of things) since they often end up getting burned by tools acquired by other groups that they must then support. Also, many non-technical groups feel out of place and overwhelmed by the idea of helping with technical standards. That said, everyone gets burned if the technical requirements and/or standards do not sufficiently support users, so non-technical input is key (even though finalization of technical requirements / standards will rest with the technical team).

Here are some reasons non-technical staff should be involved in technical standards and requirements:

Prioritization

Functionality may be discounted from a priority perspective by the technical team. Note that even if eventually a decision is made against a difficult-to-implement functionality, then at least everyone had a chance to discuss it. Many of these decisions may be largely irreversible so, at a minimum, everyone should have their thoughts heard.

“Friendly urls.” The technical team may want rewriting a la tinyurl, whereas business representatives may want only urls that “stick."
Single sign on details. Users may want simpler passwords, so a risk/reward discussion may be required.
CMS requirements. For example, user interface issues.
Browser compatibility. Business/user representatives may have knowledge that others do not about key users that require certain browser compatibility.

Perspective

More subtle, but perhaps even more important, is that the technical teams and non-technical folks may have a different perspective or angle on the same issue. This may even mean that less work is required of the technical teams (I have seen this happen frequently). Other specific examples:

Load time. The tech team may prefer looking at methods that are easy to capture, whereas from an end-user perspective other issues may be more important. For example, uncached load time on client side.
RSS. The tech team may want to just “turn on” RSS through whatever tools are available, whereas business users may look at it more broadly to include RSS analytics, RSS landing pages, RSS across multiple systems, etc.

This client/user perspective can also help define the business drivers behind why certain metrics need to be gathered and how that may impact tool selection.

Take Heat / Workload Off of IT

This one is self-explanatory and may mean more or less to your organization depending on your situation. By involving the business side, IT is naturally exposed to less criticism. Also, other teams can investigate best practices and conduct research (as well as writing out the standards, etc). In addition, the extra involvement will improve the buy-in on tool decisions.

Less Costly Mistakes or "Do-Overs"

Standards or requirements created without non-IS input can easily create situations where implementation meets significant enough resistance that work has to be redone. For example, if we take the example of “friendly urls,” if a decision is made for client side rewriting, then it may be even more expensive to change than the initial expense of doing it that way.

Other Business Process Implications

Technology is never implemented in a vacuum, so the business process implications must be considered. For a CMS, this can impact the training, editorial standards, documentation, and implementation details. Examples include:

Taxonomy management and information architecture. It's easy to underestimate the impact that simple template changes or the lack of ability of systems to manage a hierarchical taxonomy can have. The impact to the publishing process, editorial standards, and training must be considered.
SEO and the content itself. To achieve some tool standards, business users may be required to follow certain standards and write their content for SEO.

Note that this is also an attitude, since obviously it could be argued that the above could be accomplished by the IT group just going to the other teams to gather requirements. We would suggest taking a more "operational" approach where there is ongoing development and ongoing optimization, as well as improved transparency and buy-in (thanks to Lisa for raising this point).

For better prioritization, perspective, and efficiency, include your non-technical stakeholders in standards and requirements teams.

Five Suggestions for a Successful CMS Migration

David Hobbs — Wed, 08 Apr 2009 10:33:18 -0700

Migrating to a new system can be surprisingly difficult (some reasons). The following steps can help in your migration:

1. Define success and broadly communicate the vision

This step sounds so simple but is easy to be missed in the excitement and work of a migration: Clearly and simply identifying success for your migration efforts, and then broadly communicating this vision. It's certainly not enough for the success to be defined in some obscure report that no one reads. Defining success does not need to be complex, but something that is concrete enough to be testable. In fact, something simple like "1) client-focused (not company-focused); 2) broadly repurposed content; and 3) easy to change look and feel" could be a good statement to broadly communicate. There are several reasons for doing this:

Set expectations. The statement will NOT include some things that some groups think are important. Instead of people being surprised that something is not provided that was briefly discussed (people often mistake a conversation about potential functionality with a commitment to provide that functionality), this makes things more clear from the start. The best time to discuss these is BEFORE migration and not mid-way through.
Testable. These success criteria should not be so lofty that they cannot be tested. Ideally, you would define exactly how this will be tested before starting as well.
Provide focus for everyone. In the heat of the migration, there will be a lot of people asking for a lot of new functionality. By defining the migration success factors up front, hopefully everyone can stay a bit more focused.

Obviously, a key point in messaging is making sure that no one thinks the migration/launch will be entirely seamless. Of course this isn't the case, so it's best to let people know this. By having the goals clear in everyone's minds, hopefully it will make the hiccups easier for stakeholders to take.

2. Put your site on a diet

What's probably obvious is that migrating less will be less effort. By undertaking a ROT (Redundant, Outdated, and Trivial) analysis before your migration, you can restrict what content/sites get moved into your new system.

That said, a bigger issue is *ongoing* dieting (rather than a binge diet just for the migration). What can start out as an effort to eliminate sites can actually wind up being an explosion of sites depending on how you proceed. This isn't just a technology issue, but more of a Web Operations Management issue. See my Web Diet blog post for more background. Note that by setting expectations on the complexity of your site before migration, you can better control things.

3. Don't fall in love with the technology

This one is tough. Most people will fall in love (initially) or hate (eventually) the technology they use for their Web site. Obviously the technology is important, and you may currently have an Web infrastructure that does not allow you to do what you need. For the purposes of a migration, some technology traps to avoid include:

Doing something just because you can.
Only doing what the technology can do out of the box.
Blaming technology for people issues.
Not considering your content authoring strategy.

On the last point, a major advantage of a CMS can be metadata-driven pages/sites. Without considering the tagging process and quality, you can end up with even more of a mess than you have now. Thinking through your content authoring strategy means that your process and tagging have a better chance of successfully (and efficiently) driving your site.

4. Define process for prioritizing issues

The second you start migration, people will want changes (configuration changes, new features, changes for expediency, etc). If you don't have a process in place before these requests happen, then you may make changes that are difficult for your users and make your system more difficult to manage over time. See previous posts on Tool Product Management and Web Product Management for more information.

5. Honestly ask yourself: are you ready for migration?

Take a cold, hard look at your migration readiness. Of course, sometimes it's just time to migrate, and things will never be perfect. But by looking at your situation objectively, you can hopefully mitigate some risks. For instance, if you do not have the staff you really need, then putting more effort in the process for prioritizing requests may become more important. Some keys to consider:

Resource requirements. Do you have the technical resources (for migration scripting, configuration of the CMS, developing integration points with your other systems, etc); internal client support (liaisons between various units at your organization and the technical resources); editorial; training; and help desk support? Note that you can generally expect a burst of resource needs once migration starts.
Management buy-in. Has management articulated this as a priority?
Technical readiness. Putting wishful thinking aside, are the systems ready? Are your most common use cases easy enough for people who will be managing sites?
Overall Web Operations Management. Do you have the ongoing operational capabilities to maintain your site (from Strategy, Web Governance, Web Execution, and Web Measurement)? See Web Operations Management primer for more background.

Migration is difficult but by defining success (and loudly communicating this), putting your site on a diet, not falling in love with the technology, defining a prioritization process, and carefully reviewing your migration readiness, you should have a more successful migration.

Internal CMS Product Management

David Hobbs — Mon, 06 Apr 2009 10:48:14 -0700

Any Content Management System (CMS) needs to be customized to a particular institution's requirements. This customization is not solely a technical matter, and hence needs to have someone wearing both the technical and user hats to define how the product should work at all stages of the CMS product within the organization.

In other words, you need a product manager would do the following:

Define how the content publishing process should work
Work with internal training, documentation, technical support, and the technical implementation teams to successfully deploy and maintain a high quality solution
Clearly articulate the product to the internal user community, including how new features of the core product impact them (for instance, if you are using Documentum, then how changes to the core Documentum product will affect them)
Evangelize the tool (especially for initial migration)
Regularly interact with the user community to hear their concerns and suggestions

Download attachment below for full text version.

Deep or Shallow Multilingual for a CMS Implementation?

David Hobbs — Wed, 18 Mar 2009 06:57:01 -0700

Many decisions made early in the design of a multilingual site will determine the capabilities for years to come, so all aspects should be carefully considered. That said, many key issues aren’t immediately obvious when developing a multilingual Web site the first time, so this blog post aims to pull out some important questions to ask when defining the requirements of your multilingual Web site:

Overall Site Structure

Will the site be in just a few languages and the content be entirely parallel? Or will each language site basically be entirely separate, with some key page linkages? Or will some languages be used just for core areas (for instance, country-specific pages), but certain languages used for major institution-wide content? If some languages will be covered sparsely, how will lists of content be presented (see Interleaving Languages)? Also, in the case of sparse translations, do you need to support some pieces of content only partially getting translated (for example, just an abstract getting translated)?

Admin Support

Does your support team need an easy way to find content even when it’s not in a language they speak? Who will be doing your translations and are they already using tools you need to interface with? If content changes frequently, do translators of different languages then need to be notified appropriately? Do you need editing tools that support multiple languages at once, or will each translator/editor just be working in one language? Are there any special search requirements for site administrators?

Other technical issues

If you are supporting languages that are multi-byte, are there limits on any of your systems? For example, if you need to pass data to a site analytics tool, will you be able to pass all the information you need? Some languages are more verbose than others – will that effect items such as how your breadcrumbs are handled? Are all the languages you want to provide supported by current operating systems?

The Web Diet: How To Simplify Your Web Site

David Hobbs — Fri, 13 Feb 2009 09:43:32 -0800

Small Web sites are easier to manage than large ones. Since this is obvious, why don't more sites choose to be smaller?

Of course some sites need to be larger than others. A baby blog with the purpose of sharing news with family will certainly be smaller than a global suite of sites for a major corporation. Even for a site that needs to be relatively large, couldn't the organization choose to make the site smaller? Just yesterday Harvard Business blogged Simplicity: The Next Big Thing, stating that the next big trend for corporations is to simplify, in part by streamlining business processes. As part of your strategy for managing the Web in a recession, perhaps now is a good time to have your Web site go on a diet.

What does "Large" Mean Anyway?

Lisa Welchman and I have been working on the definition of Large Sites, but for the purposes of simplifying your Web site, here are some ways your site will feel Large:

Sheer number of pages, content items, or templates (definitions of each of these may vary)
Number/depth of systems/applications being integrated
How dynamic and/or automated the site is
Number of brands/sub-sites
Number of ways users can get to your content (content re-use across Web pages/brands/sub-sites, APIs, RSS, internal database calls, etc)
Complexity of interrelationships between content (for example, how complex multilingual relationships are maintained)
Inconsistencies between sites

So a baby blog may have a small number of blog posts, only one or two templates, no systems being integrated, with no sub-sites, and only available via one page per blog entry. IBM's corporate suite of sites has all of the above, to the max.

The point of this isn't to come up with a formula to calculate the size of a site (like a Web equivalent of BMI), but just to point out that you probably have size factors that can be reduced. The easiest to cut is probably the first one: the amount of content in your site. This also includes what many large bureaucracies end up creating, which is duplication of content and even sites (for example, two different groups looking at the same topic from slightly different angles). Another key way that sites get larger is by not being consistent -- adding a hundred countries sites that are all the same may make the site feel larger than adding three applications that are entirely different. But each of the factors above could be reduced as well.

What are The Impacts of a Large Site

Before diving into more about how to simplify your site, let's review *why* a larger site leads to problems:

Reduced Usability. In general, adding functionality should not be taken lightly since it can reduce the site's usability. I thought Jared Spool's tweet yesterday was compelling: "I could see an argument for reducing functions to improve UX here: Hand-managed-pages -> CMS -> Blog -> Tumblr -> Twitter". 37signals ("Our products do less than the competition — intentionally.") and others have made many successful and compelling arguments for reduced functionality to improve usability. One of the problems with a Large Web presence, if it's not Product Managed, is that functions keep arising from different groups and it winds up being a hodge-podge of confusing functionality (each on its own may even be good/interesting, but in the aggregate it's confusing). In addition, without better editing of content, even a single page can be less easy to use (having a strong Design & Editorial team can help here). Also see Paul Boag's #10 "You Have Too Much Content" in his excellent Smashing Magazine article 10 Harsh Truths About Corporate Websites.
Inability to Manage. This one is obvious, but easy to overlook. The more stuff (content, functions, sites, etc, as listed above) you add to your site, the harder it's going to be to manage it. In addition to there being more to deal with, often the nature of managing the amount of content changes. For instance, if you have hundreds of thousands of pages, then necessarily you need more people. This then means you need more training, documentation, etc.
Diluted Brand. Once you add more and more stuff to your site, it becomes much more difficult to control your brand. Of course, now your brand image is being determined in a very broad way that is largely out of control, but you might as well be in control of what you theoretically are in control of.

How to Slim Down Your Web Site

This is a bit like any other diet. There are many ways to lose weight fast, the easiest being just not moving over your ROT (Redundant, Outdated, and Trivial) information during a content migration. When that new application is proposed that gets everyone excited, however, it's tough to say not to add it (or to step back and think about how to roll it out as a beta and pull it back if not successful). So how do you keep the weight off? Specifically, how do you slim down a site that needs to be relatively large (the rules below aren't entirely relevant for small sites, since a smaller team can just make it happen directly)? Well, like a diet, the details aren't that exciting, but here's an approach:

Step 1: State slimming down as a priority

At the very top of your institution, this should be part of a Guiding Principle for the Web. At this level, it won't be very specific but key terms like "efficiently managed Web site" or "easy to find information" may help set things up. Also, senior executives need to delegate the authority to someone to actually make this happen. Yesterday at web4dev, David Pullinger reported that the UK government has been closing more than one Web site per day since 2006. Without Gordon Brown specifically pushing for this, this probably would not be possible.

Step 2: Define policy and standards to make it easier for people on a day-to-day basis to not introduce unnecessary fluff

A policy could be that only meaningful and unique sub-sites be created (possibly backed up by a policy to review any request for a new site), and that sub-sites should also follow the standards of the organization. The standards then should be defined so that even when new sites or content are added, they are added in a consistent manner which will have a slimming effect on the site.

Step 3: Set up the required teams

The exact structure of your teams depends on your organization, but one thing is for sure: you need Web Program Management, Web Product Management, Design & Editorial, and Information Organization & Access. Having centralized Web Program Management (including budget) will help ensure that spurious sites are not created. One of the most important roles is Web Product Management, where someone is managing your entire Web presence as a product. Similar to how products can be much more elegant with less features, the product manager drives the direction of the site (including saying no to some new requests). Design & Editorial and Information Organization & Access teams need to help drive the 'less is more' mantra as well.

Step 4: Measure

What's the scale for measuring site's size? This should be defined up front, tracked, and reported on. For example, if you say that you're cutting back on the number of applications on your site, then make sure there's a way to track and report that. Automated systems may help on some of the measures, such as the total number of content items in your site.

Remember:

Smaller sites are easier to manage and probably easier to use
There are many areas where a site can slim down
By taking the steps of prioritizing, setting policies and standards, defining appropriate teams including Web Product Management, and Measuring, you can make your site smaller.

Note that here I don't delve into the broader issue of your total Web presence, which includes many of the ways you interact with the world outside your site (partner sites, social networking sites, etc). If you would like to continue this discussion, please comment here or use the hashtag #webdiet on twitter.

Web Analytics: Define, Collect, Report, Repeat

David Hobbs — Thu, 12 Feb 2009 11:47:53 -0800

Many sites are dedicated to Web Analytics, which, along with a Web Usability Program and Strategic Business Metrics, round out the Web Measurement portion of Web Operations Management (see the WOM Primer for background). Here I'll concentrate on how to set up Web Analytics in your organization to help support your overall Web Operations Management. This needs to be done in three steps: 1) define what to measure, 2) set up systems to measure, then 3) report. If any of these are missing or broken, then your Web Analytics will not be effective (regardless of how slick or cutting edge your analytics tool is). So, here is how to set up effective Web Analytics, step-by-step:

1) Define what to measure

Here you want to concentrate on the goals of your Web site, which should flow from the top level Web Guiding Principles and your overall Web strategy. If set up correctly, these should be the kinds of metrics that everyone at the institution would care about (from the top down). The important thing here is to focus on your *goals* and not just whatever your statistics tool gags out by default. Make sure to consider your overall Web presence holistically, which may mean not just focusing on one tool but across multiple channels (for instance, you may want to measure how people are reading your blogs as well).

2) Set up systems to measure

Looking at what metrics to measure, the next step is figuring out how to measure them. This may require adding a new tool to your arsenal (for instance, you may need to use FeedBurner to track blog subscribes). You may decide that it's ok to only post an overall Web Analytics report every quarter, in which case it may be fine if it needs some manual steps to pull together. That said, in addition to the tools and process for pulling together the stats, you may also need to change your core systems or content entry processes. For example, if you decide it is important to see which topics are of most interest, then you may need to have a shared taxonomy across systems (and the training to ensure everyone uses the terms in the same way).

3) Report

This step is important but easy to overlook. If in step 1 you've defined metrics that are important to your organization, then fortunately there will be demand for the reports. In step 2 you may have set up systems that still need some manual work to put together reports, so you also need to make sure you have the resources to do the work. Once the reports are generated, you then need to widely broadcast them. If you aren't having people discuss (and probably contest) the metrics, then they probably either aren't the right metrics or aren't being distributed widely enough. These reports should help drive your organization's Web site in the right direction. One way this will happen, for a large organization, is when different groups within your organization start comparing themselves so there's a natural competition to improve the metrics (which, as defined in step 1, are the right metrics and not just page views or something that your analytics packages happens to easily produce).

4) Repeat

Of course, the above three steps are more of a part of an ongoing cycle than a one-time event. In fact, you may wish to start small now by going through the first three steps quickly and then revisiting. In addition, the metrics themselves will flow back from Measurement back up to Web Operations Management Strategy and back through the overall WOM cycle (which may end up impacting which metrics are collected once it goes through Governance and Measurement). There are also other little mini feedback loops that go on, with Web Product Management looking at the statistics to determine what is working and what isn't on the Web, which then may require new statistics to dig into problems that are uncovered.

The three steps of 1) define what to measure, 2) set up systems to measure, and 3) reporting should help improve your Web Analytics program. Every once in a while, these steps should be repeated to better hone your Analytics and, moreover, to improve your site overall.

Stump the Consultant

David Hobbs — Tue, 10 Feb 2009 09:22:51 -0800

The Web Product Manager: Quality via Product Management

David Hobbs — Wed, 04 Feb 2009 10:51:45 -0800

We've been spending a lot of time thinking about what makes a good Web team, and we feel that a Web Product Manager is key. The basic idea is that someone is looking at your Web presence as a product in its entirety: from Web applications to corporate communications pages, from APIs to RSS feeds, from a user perspective to overall quality and maintainability. One sure-fire way to tell if you don't have good product management (or product management doesn't have sufficient authority) is that the user experience on your site is disjointed. For example, if your external site visitors have multiple logins for different applications (for instance, newsletters and email alerts), then the Web site probably isn't being managed as a product.

Ways to product manage (as opposed to project or program management, also important) your Web presence:

Think Broadly. As mentioned above, whenever considering a new site section or functionality, look broadly at how this impacts the rest of your Web presence. It might be helpful to create a checklist of the different "flavors" of presence (for example, a publications database, email newsletter, and your blog) you have on the Web and make sure to at least consider the impact on each.
Boldly Set Direction. When you're in the middle of discussions (or more vigorous forms of communication!), there are all sorts of ideas flying around. The Web Product Manager needs to consider all these details but clearly articulate the direction of the Web. For instance, perhaps you set focus of your Web presence in the next three months to be implementing an API to your data -- that will help everyone rally around the one idea, and potentially put pet issues as less urgent in everyone's mind.
Discover vs. Gather Requirements. (See Stacey Weber's blog post with a similar title.) Users don't know the Web site like you do as Web Product Manager, so they may not even be able to articulate exactly what they want. The Product Manager needs to dig deep in the details, consider other relevant requests from other users, and often come up with creative approaches that were never explicitly articulated.
Consider the Entire Web Lifecycle. If you're managing your Web presence as a product, then it's not about making the next deliverable on time, on budget, and within scope (which is more along the lines of the project manager's role). You need to consider the Web presence over the long term, over multiple iterations. This also includes thinking about what happens with content over time (ROT, archiving, etc).
Saying No. In many ways this may be the most important, and it's so counter-intuitive. You want to make everyone happy, right? Well, as a Product Manager it's more important to have a coherent Web presence than a fifty-headed monster, with different sections of a site behaving in wildly different ways. Does the ipod have all features someone could want? No. (For instance, no FM radio.) But, it's a coherent product. Remember though that you're not just Saying No, but discovering requirements that users may not even know to articulate.
Differentiate Your Stakeholders. Related to 'Saying No,' make sure you differentiate between your stakeholders, and try hard not to just grease the squeaky wheel.

If you're interested in learning more about the concept of product management in general (not just the Web Product Manager), here are some excellent resources:

How To Be A Good Product Manager: blog
On Product Management: blog / twitter
Strategic Product Manager: blog / twitter
The Cranky PM: blog / twitter
Tyner Blain: blog

Feel free to comment below or tweet me if you have any feedback.

Geithner, TurboTax, and Content Management Systems

David Hobbs — Tue, 27 Jan 2009 05:29:58 -0800

Geithner was confirmed yesterday as Treasury Secretary, although his confirmation was not as smooth due to tax issues for the years he worked at the International Monetary Fund (IMF). When I was at the IMF's sister organization across the street, the World Bank, the taxes were confusing. Actually, the most confusing part was how to pay all the taxes -- it was quite clear what you had to do (all those forms/communications that Geithner, the rest of the Bank/Fund employees, and I saw made that clear). In TurboTax, I had to dig pretty deep, avoiding the simple question-and-answers and going straight to the tax forms. One year I went to a tax accountant instead of doing my own taxes. That didn't work out well. The accountant kept saying if I received a W-2 then I wouldn't have to pay the employer portion of the taxes. Eventually I prevailed and he figured out how to cajole his system into accepting the extra $.

There are a lot of corollaries with running a CMS:

The system should make it easy to do the right thing. A system should nudge us in the right direction. For example with TurboTax, perhaps just defaulting to select the appropriate taxes if you enter a W-2 from the IMF and are a US citizen. Of course, there are diminishing returns on adding features to systems, but if it is difficult to accomplish doing the "right" thing in your CMS, then many people will not.
People will make mistakes. Beyond nudging, if at all possible, you should design your system so that it's not possible (or very difficult) to do the wrong thing. For instance, if you have a published CSS stylesheet that everyone should be using, then the built-in CMS editor should only allow the authors to use those styles (as opposed to selecting any font). A next-best approach is to have the system check periodically if everything is ok (rather than at publish time).
Your users need to at least know what the standard is. In the case of the World Bank, the standard for taxes was quite clear. For your CMS, you should publish (where everyone knows where they are) the standards for your Web site.
Some people will be more conscientious than others. This really is related to everything above since you want to design your system so that it's easier for people to do the right thing. That said, if you know you have particularly conscientious users (and if you product manage a Web site or an institution's CMS, you should know), then it's probably in your best interest to empower these people so that they encourage others to also do the right thing.
The experts should know the rules and standards, even if only local standards. For example, in the DC area tax accountants should know that World Bank / IMF employees (the second-largest employer in DC) who are US nationals need to pay the employer portion of social security. I trust (hope?) that all of the tax accountants in the metropolitan DC area have now figured that out. In a CMS system, you may also have local standards, for example for a particular section of a site. Everyone who works on the site, but especially those who are trainers or Web team managers, should be trained on what is and is not acceptable for a given section.

Designing RSS Feeds for Information-Heavy Organizations: Non-Web Distribution of Your Content

David Hobbs — Wed, 07 Jan 2009 11:29:51 -0800

Does your organization have a lot of information to share with your users/customers/members?

If so, you probably want to distribute your content via RSS. Not only can individuals subscribe to your feeds using Google Reader, NetNewsWire, Netvibes, or whatever, but your content can then be re-used on other sites.

When asked about providing RSS, the technical team may be tempted to say "Of course, our platform can generate RSS" and provide whatever is possible out-of-the-box. The marketing or other team may not know enough to ask for more. This quick blog post attempts to at least list some questions to make sure you address when designing (or re-designing) your RSS feeds. Note that many of these questions are appropriate just for large organizations with a lot of information to provide, but all organizations may get a better understanding of providing RSS by reviewing these questions.

Questions to ask yourself when designing RSS Feeds for Information-Heavy Organizations:

When a site visitor signs up for a feed, what will they see (raw XML? a nicer view)? Will you have an HTML page listing all of your RSS feeds? For each page, what will the auto-discover RSS feed be (and will it change on different sections of your site)?
Will you provide RSS and Atom? If both, how will the user select which?
If you have a lot of information, then people will want to slice and dice that information (for instance, by country). Do you have solid and consistent metadata, across all your systems?
What systems do you want to pull from? A CMS is obvious, but what about document repositories or other systems (and will it be clear to the user what content will be in the feed and what won't)? If your organization is federated, will you be able to pull content across the organization?
How will you collect stats on your feeds? For instance, will you know how many people subscribe to your feed (they may be reading your blog but very rarely/never coming to your site)? How will your feed stats integrate with your normal Web stats?
Will you provide the complete content in your RSS or just some intro text? What does "complete" mean (if your site aggregates many pieces of content onto one page for example)?
What will the url structure be for your feeds? Will users be able to see the pattern in your url feeds, and do their own queries (for example, if it's feed.company.com/countries/td for a feed of Chad content, then can the user put in feed.company.com/countries/us for a feed of US content)? How will this url structure relate to other syndication (for example APIs) you may be doing? Can you guarantee that the urls will be permanent?
Will your feeds be cached or generated dynamically?
Can you use the same mechanism for determining if content shows on your site and when it should be in the feed? In general, what will be the trigger for including content in a feed (a change in content, only a significant change, or perhaps just the fact that a state change occurs)?
How will you handle multiple languages?
How will you test and monitor your feeds to ensure they are up and have the correct information?
Will you allow your internal users to create (and publish) custom feeds (perhaps with some sort of wizard for querying the system(s) and then providing a feed url based on that query)?

I would be interested in your comments, which you can provide below (and also please let us know if you would be interested in a fuller article on this).

Differentiate Stakeholders: the Squeeky Wheel Shouldn't (Always) Get the Grease

David Hobbs — Tue, 02 Dec 2008 07:36:25 -0800

Some of your stakeholders will be loud. Even obnoxious. If your objective is to reduce pain right now, then by all means do whatever it takes to shut them up. But I would argue that if you want to develop a strong product, then you should think carefully about who you are reacting to and who you can (tactfully) ignore.

Let me step back. This assumes that you are collecting feedback from your users and other stakeholders before implementing anything. If you aren't doing that, then the first step is to initiate an honest dialog with your users about what changes should be made to whatever system you are managing.

This could be applied to most products, but consider the implementation of a Content Management System (or ongoing product management of your Web presence) in your organization. You will have the following types of users (mostly site visitors, followed by basic CMS users and then a small set of power CMS users):

Chances are, your power users are the loudest. These are the folks who already have installed three different Open Source CMSes and develop Web sites on the side for their friends. They are very opinionated, and have just enough artillery to potentially make you look silly in large meetings (although perhaps not enough background to really understand how to go from a developed-at-home-in-an-hour implementation to an infrastructure for a large site).

In many ways, these power users are often asking for things that don't really matter, at least in the Big Picture. The people you really want to support are your External Site Visitors (or internal visitors in the case of an intranet). These are the folks that are probably even less able to clearly articulate exactly what they want, but are probably the most important. So if you are staring at a list of functionality requests, and you do manage to have an item that would benefit a regular old site visitor, then seriously consider it. This may even mean that you get yelled at by other stakeholders, but remember that your site visitors are what really matter. Here are some concrete ways that you can differentiate your stakeholders:

Make sure to get input from the different types of stakeholders you have (and make to identify the key ones)
When negotiating your next round of enhancements, potentially even have all requests categorized by the type of stakeholder that will be affected.
Whenever you decide on your next block of changes, make sure to cover each type of stakeholder (and have an especially good reason for not satisfying your largest stakeholder group, if you decide to do so).
From a measurement perspective, you could track which group of users benefits from the various changes you make.

Web 2.0 Expo NYC

David Hobbs — Tue, 11 Nov 2008 09:23:15 -0800

David covered Web 2.0 Expo NYC under the aegis of The Content Wrangler, producing the following blog posts:

Leading up to the conference, David also interviewed Lisa Welchman on Web Operations Management and Web 2.0.

For more information on the conference, see the Web 2.0 Expo NYC News and Coverage page .

CMS Implementation: Product or Project Manage?

David Hobbs — Mon, 27 Oct 2008 14:06:53 -0700

So your organization decided to get a new Content Management System (CMS), either replacing an existing CMS or as your first CMS. A strong organizational temptation will probably be to treat implementing the CMS for your institution as a project rather than as an internal product. But in addition to project management, you'll need product management. It's unfortunate that project, product, and program management all have the abbreviation of PM, and that may contribute to the confusion between these terms.

So what are a couple of ways of treating a CMS implementation from a product manager's perspective?

1. Ongoing Process. With a project view of the implementation, you will probably be managing to a milestone, whereas for a product the process needs to be looked at as an ongoing process. The product manager is responsible for the overall and ongoing success of the product.

2. Product Definition. A key responsibility of the internal CMS product manager is defining the product. This is much tougher than it sounds, since the product manager will hear a wide variety of often-conflicting requests from various stakeholders. From this mayhem of requests (most being extremely important to the requester but not so important to other stakeholders), the product manager needs to define the product.

For a CMS, this definition includes:

How much control is given to whom. Power users will want deep control of their pages, but probably one of the main reasons to have a CMS in the first place is to enforce consistency across pages. One of the greatest conflicts will be between ease of use and support for power users.
How the CMS is extended. Any extension or custom work will increase the moving parts that can break in your system (and potentially complicate upgrades in the future). In addition, adding more functionality has a high probability of also complicating the user interface. Beyond to the go/no-go decision on functionality, exactly how it is implemented will affect the usability and manageability of the CMS.
Templates. An easy way to appease people in the short term and complicate life in the long term is to start creating a separate template for each stakeholder. The product manager needs to negotiate with the stakeholders to appropriately create templates that are re-usable across as many pages / sections of the site as possible.

Much of this boils down to the product manager deciding what not to include in the CMS implementation. Since there is no way of fully implementing everything the way everyone wants, this involves a lot of discussions with a variety of stakeholders to deeply understand and respond to the most important requirements.

Next week at jboye08, I'll be giving a talk Planting a Flag vs. Engaging Users that explores how to product manage a CMS implementation.

There's Data, and Then There's Using Data

David Hobbs — Fri, 24 Oct 2008 08:40:27 -0700

If one way of looking at Web 2.0 is that it's a Data Operating System (per Tim O'Reilly), then there are two important elements shaping up:

Accessing Data
Using the Data

Using organizations in Washington DC as an example, several organizations with a lot of useful data are tackling these issues. The World Bank, for example, has launched it's api.worldbank.org and also a tool that users can explore the data with. The Center for Global Development and Confronting Climate Change Initiatives have an API for accessing carbon emission data, online tool for visualizing carbon emissions, including widgets that can be placed on your own site.

The DC Government has an impressive catalog of data that is made available for people to create their own mashups, and also provides maps that reflect the data. Now, the DC government has launched an innovation content, offering a prize to companies or individuals that develop innovative applications using this data. One iphone app has already been developed that is a "realtime, location-aware DC alerting tool for the iPhone, which includes crime reports, building permits and more." For those of you interested in participating in the contest, the submission deadline is November 12th.

You Are Here: The Political Layer

David Hobbs — Tue, 07 Oct 2008 09:04:49 -0700

One of my favorite t-shirts is a geeky play on the seven OSI layers of networking. This shirt basically emphasizes that sure there are all these technical aspects that many of us are supposed to be working on (and perhaps learned about in college), but we all spend a lot of our time on political and other people-based layers (see also Layer 8). Regardless of what your job is nominally, there is always the political layer you have to deal with.

Web Operations Management (WOM) attempts to put a structure in place for running your Web presence, which navigates the political realities of your organization. Instead of pretending these realities don't exist, you can explicitly define the WOM Strategy, Web Governance, and Web Execution that such that it fits within your political environment. By setting these structures in place, this can also mean that you get political cover from higher up rather than being tossed about in the wind by the loudest voices asking for changes to your site (for instance, you could potentially appeal to a higher-level governance body about why you cannot make a requested change).

Be Ready: Initiating CMS Migration

David Hobbs — Sun, 07 Sep 2008 19:11:12 -0700

CMS migration is a resource-intensive undertaking. The following graph of central team effort isn’t strictly accurate but hopefully will illustrate some key points:

•    The first users will find issues that were not yet identified in pilot, as actual usage always uncovers nuances not found in earlier stages. Even with very tight product management (so you aren’t just whipsawed implementing various whims of clients), there will probably be a burst in the central team’s effort when the very first users use the system to implement changes and workarounds and also communicate these changes.
•    Although perhaps not at as high a level, the required level of effort will continue to rise as more and more users enter the fray, but at some point (perhaps after 80% of sites are in the system) the central team effort should start going down.
•    The central team’s effort level will probably never go back to the level it was at during the pilot.
•    The steady state is represented as a flat line below although there will be occasional bursts to implement special initiatives. Since that’s in the steady state, that won’t be a focus in this document.

How do you brace yourself for this? Some pointers:

Define a process for responding to feature requests (and not just trying to implement every request that comes in).
Attempt to clearly separate between changes to core CMS, templates, and items that end users can control, and treat each kind of request uniquely. Ideally, only very sound changes are made to the core CMS, and most other changes are made to global templates.
Ideally you should have a strong support team (including training, documentation, and liaisons between the implementors and user groups), technical team (the folks that can implement any changes that arise) as well as a product manager to ensure that changes are made in a way that keeps the CMS coherent / logical.

Planting a Flag vs. Engaging Users

David Hobbs — Sat, 30 Aug 2008 19:47:44 -0700