What Factors Should Be Ignored?

It's easiest to start with some traditional sources of requirements that should not be taken into account.

What the current system does

The starting point for most content management projects is an old CMS. Requirements are defined in terms of things this system does, and in things that people wish it didn't. While these may be genuine concerns, they are reactions to the current system, rather than being driven by the current business needs (assuming that the project is not an upgrade of the existing system). The view should be as if there were a blank slate, and the company had no CMS. The pains of everyday use should be involved in the development of the replacement, but in terms of the details of how content is managed, rather than the broad picture of what the site needs to accomplish.

What technology is involved

It's important to stay focused on what is wanted, rather than what is possible. This is because what is possible varies from technology to technology, from level of investment, and most of all it varies over time. Even if an experienced technical person is involved, their expertise may lead their focus - the front-end expert may miss the opportunities in targeting smart phones, or the database expert may not be aware of the latest web services available. Framing the needs in a technology agnostic manner means that the focus stays where it should - in what will deliver value to the business.

Having said this, it is always recommended to look for compatibility with your existing in-house technology stacks when selecting a new CMS. If a certain feature will bring significant business benefits, but isn't available on your current platform, it might be worth considering changing the platform. All of this naturally plays into costs. These are, however, constraints that should be considered only after the requirements have been properly gathered.

All-new functionality

As much as the sales team might want an integrated CRM and live chat, individual desires should not be what's being collected. This might seem strange - surely finding out what people want is what requirements gathering is about? However, it isn't, for two reasons. Firstly, the site should be about fulfilling goals - and a goal doesn't describe the manner of its achievement, just a way of judging its success. Secondly, what people want is very much influenced by what they have now - many of these requests are driven by deficiencies in the existing system, leading to a new system that also has the deficiency rather than resolving the root cause. This is not to say that there won't be new features - but they should be driven by the business rather than individual desires, as we look at below.

What should be considered?

What it needs to do right now

This is dangerously similar to the problematic area of what the current system does. The difference is all in the approach. For example:

Instead of: "There must be a file download area." (as on the current site)

Define it like this this: "Users must be able to access the white papers and training videos."

List the things the users absolutely must be able to do, and keep the user focus on the result, rather than the method.

What it will have to support

In general, for the reasons above, new functionality should be avoided. However, to deliver value the site will need to support the other efforts of the company. The goal should be to look at the in-flight projects in all parts of the company, and identify where the CMS could support, enable, or enhance these projects. Again, the focus should be technology agnostic, and purely on what would help the projects most. This keeps the requirements focused on what will make a difference to the business.

What end-users try to do with it

There is an important subtlety here - this isn't about what users want, it's about the kinds of things they try to do. Everyone that's launched a product knows what users say that want and what they actually make decisions based on are two different things. However, what they try to do can reveal a lot about what they think of the site. The data can come from user testing, or ideally from existing conversations online. For example, if users have created a forum to deal with support issues for your product, then maybe the current knowledge base or support mechanism is falling short of what it could.

How to replace it

This might be the earliest stage of a new CMS, but it's still worth considering the exit strategy. These kinds of requirements are about retrieving the content, documentation, and any other issues that might impede a smooth handover.

Staying On Track

To help guide the process, consider the business needs in terms of content, interaction and navigation (in that order):

• Content: Why will users be coming to the site?


• Interaction: What will they do when they reach this content?


• Navigation: How will they reach the content? How will they continue after?

The navigation requirements support, and fall naturally out of, the interactive and content parts. Again, don't worry about exactly how this will be implemented, or try to map out where each page will link; just list the requirements that the design will need to fulfil.

What Next?

With the high-level requirements in place, the next step is to assign rough priorities. This should be enough to begin the process of turning the requirements into a site through the usual mix of technical, creative, and business work. By starting with this process though, the goals and vision of the site should be clearer and easier to communicate, and lead to a far better end result.