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.
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.
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.
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.
|
Page Options
|
