Submitted by David Hobbs on 8 February 2010 - 2:06pm
Most written requirements / use cases are limp, not getting to the essence of the goals (see Where's the juice in your requirements?). Why does this happen? Often, since tough decisions are not being made.
Requirements should be focused and targeted to meet your goals. Since it is probably more painful to make changes later in the process (for instance, after implementation has started), making the tough decisions needed for focused requirements should be a priority.
Of course, some readers may argue that traditional written requirements are less effective than a more iterative, generative agile approach. I also like the iterative approach, and in fact it can aid in decision-making (for example, since working code is something that all stakeholders can respond to during the process). That said, sometimes requirements written in advance are needed, for example when selecting a Content Management System.
Some Types of Unfocused Requirements
These are some of the types of requirements documents I've seen that show a lack of decision making:
Shock and Awe
Some requirements documents obscure the real purpose of a system since they are so "impressive". These may inspire comments like "Wow, that requirements document is 100 pages and I barely understand any of it! That must have taken a lot of work! You're so smart!". The main problem here is that if stakeholders cannot understand the requirements, then there cannot be true agreement on them. Although these may impress some, they still probably lack much strength since it's hard to see the point.
Ambling requirements are also common, and these often result from requirements being gathered rather than analyzed and synthesized. Ambling requirements may contain flashes of important requirements, but are buried along with unimportant requirements or even inconsistent requirements. Listless requirements may also be too detailed in places.
Some requirements documents read like "car must have a driving wheel and four wheels" rather than "sports car primarily used to race on a racetrack on the weekends". One is certainly a fact but doesn't help in, for example, selecting a car. The second one shows a bit more of the flavor of the true requirement.
One requirements documents can have both of the problems listed above, but they can all be helped by better decision-making.
How to Tell if Your Requirements Are Unfocused and What to Do About It
How to know if you haven't made the decisions you need:
You resist efforts to prioritize your requirements.
You are excited about a possible capability, but have not written the related requirements since the relevant decisions haven't been made.
An outsider reads the requirements and does not understand overall what you are trying to accomplish.
How to make the decisions you need:
Define a compelling vision. In other words, big picture what are you trying to accomplish?
Make sure the requirements are synthesizing. People do not always know what they want, so everyone's input on the requirements should be synthesized into a coherent whole. A good way to see if the requirements are coherent is to ask someone uninvolved (but aware of the general area you are writing requirements for) understands them quickly.
Even though it is hard, prioritize your requirements. Many resist the concept of prioritizing requirements, since a requirement is a "must have". Of course you don't always get everything you want, but, moreover, you want to make sure that your highest-priority requirements are easy and straightforward in your implementation. Perhaps a lower-level requirement could be satisfied with a bit of a hack.
Consider the purpose of your requirements. If you are selecting a CMS, then really the only requirements that matter are those that will differentiate one product from another (based on your objectives). If you are handing off development in bulk to another team, then the requirements need to be more exhaustive. The general point is to concentrate on the requirements that matter for your current task at hand.
What are some of the ways that pilot can be confusing for your site visitors? Here are some problems and suggestions for improvement:
Not Knowing Where the Pilot Begins and Ends
One of the keys to deciding what to pilot is choosing whether the site visitors will clearly understand where the pilot starts and ends. So before talking about any technical or implementation details, the selection should just make sense. For instance, if you have a clothing site then a possible piloted site would be the women's clothing store. This might make good sense to your set of users. Note that one of the reasons that you might be undertaking a new site is to consolidate different systems, so you may be piloting a new site that contains content from multiple sites. See the example diagram below, where some content from two subsites is being piloted in one site. Using the clothing example again, this could be where there are currently two separate sites that include all of your clothing, and you are eventually merging to one. You could pilot a women's site that will include content from both of the existing sites. At any rate, the key is that, even before considering the technical implementations, the site user should understand what is piloted and what is part of the old site.
Not Knowing When Leaving the Pilot Site
In addition, there are some ways you can implement the system to make it more obvious for the user whether they are on the piloted or existing site, including:
Indicating when leaving the piloted site. You may wish to implement a standard intermediate page that the user sees before leaving your piloted site (see #3 in the diagram below). At least that way the user has the opportunity to back up if they want to stay on the piloted site.
Clearly branding the piloted site. You also want to make sure that visually the piloted site is quite different from the existing site.
To Beta or In-Place Pilot
One question will be whether to just plain replace an existing subsite or to do a Beta that users can optionally try out. One advantage of a Beta is that you can have one entry point (the Beta home page) where you can explain to your users what the Beta is, including what the advantages of the new site will be (see #1 in the diagram below). If launching a subsite in place, then you also need to be ready for deep linking to your site. This can also be an advantage so you can do a live pilot of your rewriting rules, but a disadvantage is not being able to explain the new site as easily.
Unnecessary Linking to "Old" Site
If you blindly cut and paste content, you'll have a whole lot of links going straight back to your old site (like the ball dropping in the whole in the game above). This is because you probably will have hard links to your old site within the content. Some links will need to point to the existing site and others to the new site, depending on if the target content is moved into the pilot as well. If you are doing an in-place pilot instead of a Beta, then the old links should continue to work but you still may prefer to get the links "right" anyway (for example, if you want to use managed links that some CMSes offer).
As an example of unnecessary linking, let's say you have two pages B and C that will be piloted. If you just move the content without changing the links, you'll wind up on the old site when click from page B on the new site. Obviously you want to make sure to link from the piloted B page to the piloted C page (see #2 in the diagram below).
The pilot needs to launch an actual subsite, but which one? There are two key factors:
Ensure the subsite will meet the objectives of the pilot
How easily the subsite can be teased out of the rest of the site
Before diving into some of these details, note that if you have a very large suite of sites that you will be implementing or migration then you may be more likely to launch a site as your pilot (rather than a subsite).
Ensure the subsite meets the objectives of the pilot
You may be tempted to pilot whatever is easy, but that would not really help you much as a pilot since you probably would not learn much of importance. One of the most important things to keep in mind is your pilot needs to test how well your compelling vision for the site will be met, so that you can quickly correct course if your vision is not being met. Including the compelling vision, the subsite you select should meet the objectives of a pilot:
Test key aspects of your compelling vision
Test virtually all aspects of the eventual migration:
Deployment (making the site "live")
Integration with other systems
Feedback, with the intention of making changes prior to migration
From actual web site visitors
From the core redesign team (inevitably, the more "real" the system gets, the team will see more issues and uncover more miscommunications)
Estimate effort levels, which requires:
representative content types (again, not just the "easy" ones)
not just your super stars doing any manual migration, but a representation of actual users
Many subsites will probably be ruled out by the list. For instance, a subsite that just has one content type and only a few users would not work because a) you won't be getting a good estimate of the effort for moving all content types, and b) you might not get good feedback. Note that you may not be able to accomplish all of these objectives, but by thinking about them you can better choose a site and plan your pilot. On the objective of estimating effort levels, you will also need to establish a method of tracking people's effort (such as using some sort of automated reporting, or even a spreadsheet).
How easily can the subsite be teased out from the rest of the site
Broadly speaking, there are two ways of launching a pilot: a) replacing an existing subsite entirely, or b) as a stand-alone beta site (with a prominent link such as "Try the PuppyWeb Beta!"). Some advantages of replacing a site "in place" are that you are doing a deeper test, with all of your current users on a richer set of functionality. For instance, you can test url rewriting directly to see if your old links will still work (if that's what you are attempting). A stand-alone beta is easier to take down in case of emergency, and also is easier to extricate from the rest of the site. So which approach you take depends on your particular objectives and constraints.
Regardless, you will almost certainly have to think through linkages between the site that you are piloting and the rest of the site. A major factor in deciding on what subsite you pilot may be how easy it is to decouple / couple from the site. One helpful set to defining this is to draw a high-level architectural diagram, highlighting the interrelationships between systems and subsites. These are some of the factors to consider in how the piloted subsite will relate to the existing subsites:
Internal references between content within the subsite under consideration
References between your existing site and this subsite
Other linkages with organization-wide services and reporting, such as site-wide search, site-wide RSS feeds, and site-wide statistics.
References to the subsite from outside you site entirely (for example, Google references)
How identifiable the subsite will be to site visitors (will the delineation between piloted and "old" subsites be clear to the visitor?)
If a subsite already "stands alone", then it may be easier to migrate that. If an objective of your new overall site is better integration, then you may be able to highlight that in the pilot (by pulling content from both the "old" stand-alone site and content elsewhere).
Submitted by David Hobbs on 30 November 2009 - 10:43am
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.
Submitted by David Hobbs on 12 November 2009 - 10:33pm
You're staring at a seemingly insurmountable pile of content that needs to be moved. For whatever reason, you are moving to a new content management system. How are you going to migrate this stuff? A natural conclusion is that you'll have to manually review, edit, and move content. That is understandably intimidating and would probably take a huge amount of time and effort. Moreover, especially for a large site, a manual approach has many other issues including lower quality due to inconsistency in decisions that the various editors make. Furthermore, even if you are going to be doing a lot of manual work, you should still look at the problem as a whole and break down the steps rather than just dealing with each piece of content in isolation.
So how can we turn this mess of content into something that is easier to deal with? In the following steps:
Divide the problem into manageable pieces
Take time to pilot and estimate
Re-assess based on your pilot, and migrate
Step 1. Divide content into manageable pieces: type, cut, automate
The first step is to break up your content into types. You may be lucky and your content is already neatly arranged or easy to identify. Or you may have work to be done to figure out your content types. You will need to do content analysis anyway to move into your CMS, so the first step in in the process is categorizing your content by type. To use a container ship analogy, instead of looking at the shipyard full of containers as a whole, start looking at each type of container separately.
The reason to break your content into types? You'll need to do that for a variety of reasons such as defining the metadata (which will help enable site behaviors) as well as define the editorial requirements on an ongoing basis. For the purposes of planning your migration, breaking into types will help you decide what to cut. You may feel that your press releases over five years old don't need to be moved, or the encyclopedia you tried that didn't work can be deleted.
One of the main take-away points here is that you want to define the rules for cutting content. For smaller sets of content, this may not be needed and evaluating / identifying from spreadsheets listing all content may work. But hopefully you'll be able to define rules that will allow you to not even have to take a second look at those that were cut. Defining rules may allow you to just cut wide swaths of content that isn't contributing value to your site. Some other ways of deciding to cut could include web analytics (cut anything that hasn't received page views in the last month), site section (not just the encyclopedia entries, but the whole encyclopedia site), metadata that already exists (the topic "parcheesi" doesn't interest anyone, so delete anything tagged to it in the current system), or even contributor/source (perhaps everything that intern entered three years ago can be safely deleted).
Next, you want to decide what you can automate. You've already decided what will be migrated, so now you need to decide what's going to be automatically moved. Automating isn't an either/or proposition, and in general you want to automate as much as possible. Again, the idea here is to define the rules about what will be automatically migrated and what will not. This will be useful in helping you estimate your effort and help prioritize. The biggest issue on what can be automatically migrated and not is the structure and "regularity" of the content. If you had a bunch of content that was already in a CMS, only referred to a common CSS stylesheet, was only in standard HTML, already had high quality metadata, and all the relationships between content was clearly defined, then you could migrate that easily. That's because in that example it's structured and regular. Chances are, your content is more interesting and varied (and hopefully less interesting once in the new system), so you will need to look at samples of your content and try to determine how regular and structured it is. If you can see patterns (which can be more art than science to find), then you hopefully can automate the migration of some portion of some/all content types.
After Step 1 of typing, and then finding rules for cutting and automating, you will have a more useful inventory of your content, with numbers like this:
Step 2. Take time to pilot and estimate
At this point you have some big numbers based on educated guesses, but you could still be wildly off on how many can be automated. At this point, take this one step further and try to estimate how long it will take to do the manual migration and automated migration. You might say that the press releases just need a small amount of manual massaging, so each one will take an hour on average. But perhaps those articles that you want to manually touch require actual rewriting, so will be four hours each. Using the numbers from the table above, this would mean the manual migration of the press releases is 5,000 * 1 hour = 5,000 hours and the effort for the articles would be 8,000 * 4 hours = 32,000 hours. This probably is more manual effort than you're willing to take, so you probably would cycle through Step 1 to see what other assumptions you might be able to change (for instance quality).
Let's say after your do your further analysis, you think a larger percentage of your content can be automatically migrated. Well, until the rubber hits the road, you won't really know if those assumptions are true. At this point, you should pilot an actual migration of a section of the site. Then you can actually see how much can be migrated and, by doing a sampling, you can discover how good the migration quality is (and potentially cycle through iterations to improve quality).
Step 3. Re-assess based on your pilot, and migrate
After the pilot it complete, it's time to re-assess where you're at. Did the automation yield the quality you were expecting? Are there ways of improving the quality through the automation rules? Are you going to need to jettison more content, or lesson the quality? You may decide that you need to do manual QA on a certain sampling of the automation on some content types, to confirm that the quality is working out over a large batch of content (this may also vary based on content type). See Why estimate? I'm not getting more resources for this site migration.
In sum, this is the overall process of migrating content:
After you have done the pilot and re-assessed, you should:
Have a good estimate of the effort it will take
Get a flavor for the types of issues you will be encountering
Have a way of breaking down the problem for the actual migration.
A final note: you may feel a bit of a deer in headlights with the issue of whether something can be automated or not. I've heard some interesting excuses from systems integrators / development shops about why something cannot be automated, which may sound like valid reasons to you. Hopefully by conducting your pilots and estimates, you will have compelling reasons to automate as much as possible. As mentioned above, it can be a bit more art than science in seeing patterns and being able to apply them, and it certainly should go beyond throwing a tool like HTMLtidy at the problem.