Using business requirements for successful content management projects

Author:

Date: 02 August 2007

This is a revised version of the presentation by Peter Meyer at Open Publish 2007 in Sydney on 2 August 2007.

Vendors of complex software systems are increasingly aware of the need to understand customer needs and offer tailored solutions, not lists of product features. This trend is not matched on the customer side. All too often, organizations investigating new systems seek proposals from vendors using lists of required features with little or no context or definition of the problems that are to be solved by the new system.

Focussing on documentation and content management systems, this presentation explores the differences between requirements and feature lists and explains the benefits of defining your business requirements and using them to establish clear project goals, build internal support for your project and obtain the best information from prospective solution vendors.

Contents

What is the problem with your current system?

The key ingredients of a successful systems project

Using feature lists in proposal requests

Problems with feature lists

Understanding the business problem

Using business requirements

Conclusions

Using business requirements for successful content management projects

What is the problem with your current system?

You may have identified a problem with your current documentation, content management or publishing system that you consider is inhibiting business in a significant way. If so, you are faced with a daunting problem: how do you translate that understanding into concrete action within a complex organization?

The following discussion looks at some common approaches that inhibit effective change and describes approaches that will produce more successful results.

Any system change project involves moving from the existing situation to a new, desired position. This can be seen as moving from the plains to a higher plateau. Navigating to that higher plateau involves many challenges, as shown in Figure 1.

Figure 1 Changing position

The key ingredients of a successful systems project

Bringing about change of systems in an organization is always a challenge. The following six ingredients are the minimum requirements for a successful result:

(1) Everyone involved in the project must have a clear understanding of the business problems and project goals to maintain focus and for effective communication to other stakeholders.
(2) The project must be supported by senior management who have to allocate personnel and other resources to the project.
(3) The project must have a realistic budget.
(4) The project must be supported by other people in the organization who will use or interact with the system.
(5) A solution proposal and implementation plan must be developed.
(6) A capable solution developer or system vendor must be found and engaged to execute the plan.

Using feature lists in proposal requests

In the writer's experience, many system projects are attempted without working through the earlier of the key ingredients of a successful project. This is usually demonstrated when the organization issues a request for proposal in the form of a detailed list of features expected in the new system. Unfortunately, this is common across the spectrum with government agencies, large corporations and small and medium businesses.

These feature lists are often called “requirements” and it is not uncommon that they are all stated to be mandatory. Sometimes a request for proposal may include many pages of these features, dealing with every aspect of a system envisaged by the writer.

Feature list requests frequently lack any information about the business problems and goals driving the project or explanation of who is expected to use the system and how. Vendors receiving the request have no way to determine the relative importance of each feature requirement and if their product or service is actually relevant to the needs of the requesting organization.

If a product vendor wants additional information, there may be no other written requirements information. Often, it is necessary to obtain that information through a face to face discussion with project personnel.

While feature list proposal requests are common, do they really help organizations achieve their goals?

Problems with feature lists

Defining the problem and building internal support

In anything other than the smallest organization, many people will have input into and control over a systems project. If the project involves more than trivial resources, it won't be able to proceed without support from management.

Senior management is focussed on strategic business issues and cannot realistically support a project and allocate resources to it if the only information they have is a list of system features. Management must be able to understand the problems and the project objectives in strategic business terms.

In a business context, the need for change normally will be based on one or more of these goals:

• the need to fix a broken system that inhibits or will shortly inhibit current business;
• the desire to reduce production costs that are now perceived as excessive;
• the desire to establish systems to take up a new business opportunity; or
• the need to satisfy government regulatory requirements to avoid potential penalties or other costs.

If the project is not based on these goals, it will not be able to secure critical management support or funding.

Common feature list requirements do not define the business problem and provide no assistance for building internal support for the project.

Establishing a budget

Before a proper budget can be established for a project, it is usually necessary to prepare a business case. The essential ingredients of a business case are:

• a description of the problem or opportunity;
• an estimate of the costs or lost revenue resulting from the problem;
• a description of a proposed solution;
• a list of the benefits expected if the proposed solution is adopted;
• the projected costs of the solution;
• an analysis of significant risk factors and their likely impact on the project;
• the net financial benefits in a form required by the organization's financial managers.

If only a feature list is prepared, the writer must make a set of assumptions about the nature of a solution to the problem. Usually, there are several approaches that could be taken to solving a system problem. Unless the writer has done extensive research and is very sure of the best approach, there is a very high probability that assumptions used in the feature list will be wrong.

If a prospective vendor does not understand the problem, the vendor cannot provide all the information needed for a proper comparison with other proposals. In addition, the vendor may leave out a necessary and expensive component from cost estimates because the need for it is not understood. The feature list may lead vendors to provide a low-ball price to avoid being knocked out at the first round of evaluation.

Basing a business case on vendor responses to feature lists means that the best solutions may not be identified and vendor cost estimates may be unrealistic. Reliance on a feature lists adds a high level of risk to the project.

Evaluating vendors and products

It is very difficult to assess competing, complex technical systems. They are each designed for a particular purpose. The way they actually work in practice and their strengths and weaknesses in a particular context may be hard to determine.

Take, as an example, web content management systems. There is a very big range of these systems on the market today. The features offered by many web content management systems appear to be similar. However, many of them go about their job in very different ways. Usually, it is how they work that is critical to an evaluation. These principles apply to all complex technical systems.

The best way to evaluate competing systems is to tell the vendor exactly what you want to accomplish. The vendor understands its product. If it also understands your needs, it can easily tell you whether the product is suitable.

It is very easy for a vendor to tick the boxes on a feature list. It is much harder to commit to deliver functional results for which the vendor can more easily be held to account later. Feature lists make it very difficult to evaluate competing products because they don't use real solutions to business problems as the criteria.

Measuring success

If the project has financial implications for the organization, the project proponents may be held to account for the ultimate success of the project. It is very easy for management to expect much more than you can reasonably deliver. There may be many possible benefits from a project but it may be impracticable to try and achieve them all at once.

A clear statement of project goals will help to manage expectations and provide a way to measure ultimate success. A feature list does not fulfil that need.

Conclusions on the use of feature lists

It is clear that, on their own, feature list requirements do not provide adequate value to the project. Rather, reliance on feature lists may seriously increase the risk of project failure.

When a feature list is issued as the requirements for a project without business context information, it is a strong indicator that the first four ingredients of a successful systems project have been skipped or undertaken in a perfunctory manner. It is very likely that the project will lack real management commitment and funding. How can management commit to something it does not understand?

Feature list requirements may contain valid statements of requirements. However, to be useful, they must be adequately explained and related to the project objectives. They should not be based on risky assumptions about the technical basis of possible solutions.

Feature list requirements make it difficult to distinguish between competing vendor offerings.

Understanding the business problem

Asking the right questions

As discussed earlier, a business project can be justified only if it is focussed on fixing a broken system, reducing or avoiding costs or increasing revenue. To base the project on those goals, it is essential to ask appropriate questions. As an example, here is a list of initial questions that a solution vendor might ask about a user assistance documentation system:

• What is the underlying product or service you are supporting with documentation?
• Who are the users of the documentation?
• What kinds of documentation do you provide and in what formats?
• How do product users access your documentation now?
• What languages must be supported, how are translations handled and what does translation cost?
• How do you create and publish documentation now?
• What problems do your documentation users experience with the current documentation? Determine whether these problems cost money or restrict revenue and how.
• What improvements do you want to make to documentation for your users and what benefits do you expect from those improvements?
• What problems do you have internally in producing documentation now? Describe these in terms of the costs or lost opportunities.
• What improvements do you want to make to your current production process and what benefits will those changes provide?

Clearly, there is a great deal more detail than this that must be uncovered. However, these ten questions, or similar questions applicable to your circumstances, will provide context to enable the questioner to drill down and uncover the important detail.

Defining business requirements and project goals

If you have defined your project goals in terms of solving business problems, the next step is to prepare a white paper or vision statement that will enable you to communicate those goals to others. The key ingredients of the vision statement are:

• a description of your current operations relevant to identifying your problems;
• a description of the problems, arranged into groups based on common factors such as “content authoring”, “translation”, “support costs”, “forgone sales” etc.
• an estimate of the magnitude of these problems, in financial terms;
• a statement of your objectives in solving those problems, in order of priority;
• an estimate of the benefits you expect if the problems can be solved. This may be tied into the statement of objectives, say to “reduce translation costs substantially (if possible define such a goal in terms of a percentage reduction)”.

The vision statement may be updated as the project evolves but it will provide a constant reference for the goals of the project. The first use of the vision statement will be to persuade relevant managers that there is a serious problem that justifies further investigation.

Using business requirements

Building on the vision statement

Once you have established initial support for the project, the vision statement can be used as the foundation for a range of documents that must be prepared in the ensuing stages of the project. Those stages are shown in Figure 2.

Figure 2 Using business requirements

Business requirements

Normally, the vision statement does not state actual requirements for specific parts of the new system. Such requirements are not necessary to build internal support for the project.

Once management accepts the ideas promoted in the vision statement, the next step is to ensure that a realistic solution is available and to establish a business case. This can be the most difficult part of the project because most of that information is available only from experienced consultants or product vendors.

If you included provision in your vision statement, you may be able to engage a consultant. Otherwise, the only way to obtain reliable solution and cost information is to ask prospective vendors. It will help if you can make the prospective vendors' job as easy as possible and if everyone is working on the basis of consistent information. The best way to do this is to extend the vision statement with a description of the functionality you want for the new system. These requirements should describe business functionality and not assumed product features.

Business requirements should be organized into functional groups. Each group should include a description of the problems with the existing system and the changes that are needed. Specific business requirements can be stated as distinct numbered items. It should be possible to relate each requirement to one or more of the key objectives set out in the vision statement.

The business case

The business case is built on the vision statement but, as discussed earlier, it must include more detailed cost and benefit information. Much of that information will come from using your business requirements to obtain information from prospective solution vendors.

The request for proposal

If the business case is accepted by management and the project given funding, the next step is to prepare and issue a request for proposal. Depending on the result of the business case process, you may need to revise the project goals to align to the level of funding that is available.

The request for proposal is built on the business requirements. Depending on the complexity of the project, it may not be necessary to make many changes. In more complex cases it will be necessary to add more detailed requirements.

Conclusions

It is essential to plan a project around business requirements, not around assumptions about required features. The use of business requirements lets everyone focus on what is really important in the project.

Without a vision statement and business requirements, it is unlikely you will be able to obtain meaningful support from management for the project. The project will be left to be funded out of the petty cash budget, if it is funded at all.

Concise business requirements will ensure that the project is aligned to real business needs and that risks can be more easily managed. A well founded business case will ensure that project can be properly funded to maximize project benefits.

Business requirements will enable you to obtain more reliable information from prospective product vendors for use in your business case and let you more easily compare solution proposals.

Finally, the vision statement and business requirements will provide a clear measure against which the ultimate success of the project can be assessed.
 
         Updated: 17-08-2007