Documentation system projects all too easily proceed as tool selection or prototype system development exercises that solve only limited problems.
This presentation explains how to plan a project using a business case to ensure the project is aligned to business needs and adequately funded.
Planning begins with a clear understanding of the needs of documentation users and areas where existing systems do not meet those needs.
Change can be based only on clear financial benefits such as reducing costs and increasing revenue that are demonstrated in a business case.
The business case itself involves substantial effort and expense. It is usually necessary to develop a white paper or vision statement to secure support for the business case development.
Introduction
Managers of product or
service documentation are flooded with a regular flow of new technology and
vendor offerings. How do you filter these inputs to determine what you really
need when you start to review existing systems?
Unfortunately, the flow of information focussed on technology and
tools can lead us to ask many of the wrong questions when we are faced with a
need to change how we manage documentation. If we ask the wrong questions, it
is no surprise that we may not obtain the result we really want.
This presentation provides a guide for documentation managers to
assist them to ask the right questions and follow processes that will achieve
the best solution to documentation system problems.
So, what is the problem?
Often, there is a particular issue that motivates a review of an existing
system. For example:
Software tools may
be obsolete.
The company
may be moving into new markets and it is necessary to provide documentation in
multiple languages.
Another division may be complaining about delays in a product
release because documentation is not ready.
In these cases, there is an imperative to change. These change
points offer great opportunities to consider wider issues with documentation
systems and make other changes.
In many other cases, someone questions the status quo
and may discover other issues:
Content
cannot be published effectively in multiple outputs to meet user
needs.
Users cannot
easily find the information they need so they call the support
desk.
Information is not
accessible to users where they work, e.g. in remote locations where machinery
must be serviced.
Customers
servicing equipment may use parts from third party suppliers because its hard
for them to get details, prices and to order parts from your
company.
Customers may be
unable to customize documentation to reflect changes to their procedures or to
equipment specifications following refurbishment because the documentation is
not available in a suitable format.
There is excessive duplication of content across documents, making
it difficult to maintain and update.
Due to duplication, inconsistency or complexity of content,
translation to other languages is excessively time consuming and
expensive.
When changes
are made to corporate styles, output requirements or software systems, it may
be necessary to re-format large volumes of content at very substantial
cost.
The costs of
production and distribution of printed documentation may be
excessive.
Content authors
waste time dealing with re-formatting and presentation issues that should be
handled automatically.
Look at almost
any documentation system and it is likely that more than a few of these
problems are present. They result in lost opportunities, production delays,
high content production costs and excessive support and training costs for many
enterprises.
What would be the financial benefits to
your organization if these problems could be removed?
A common but wrong place to start
In many organizations, documentation systems are seen as ancillary
to core business functions. Senior management may not easily recognize the
costs of outdated documentation practices or the opportunities to use
documentation to improve customer satisfaction, drive sales in new markets and
reduce training and support costs. Management may not readily allocate a high
priority to documentation issues. It may take some clever work to get
management attention and secure meaningful funding for a documentation
project.
In this environment, documentation managers
may attempt to find the quickest way to a solution based on a tiny available
budget. The first step may be to approach vendors to find out what various
tools can do and how much they cost.
Another
approach is for internal developers to begin development of custom prototypes
that may become working systems that solve just a few of the real
problems.
The fundamental problem with these
approaches is that they are based on the question: What tool do I need?. This
is absolutely the wrong place to start. The real question is What problems am
I trying to solve or what business results am I trying to
achieve?
Tool searches and prototype developments
can easily be based on searches for features. This leads to the issue of
requests for information or proposals that are check lists of supposedly
required features. Often there is barely a word about what the system is
supposed to do and for whom or what problems are to be solved.
Unless the requirements are quite simple, there is a high risk
with both approaches that the solution is not really aligned to the needs of
the business. How will you ever get the funding to purchase the system you
think you want unless its value is demonstrated to management?
How do you demonstrate to management the value of a proposed
solution?
The right place to start
The solution is to take a more business
focussed and structured approach to project planning from the
outset.
Management support will be secured only if
it can be demonstrated that improvements to documentation systems can save
money and improve revenue. The mechanism for this is a business
case.
A good business case can
only be prepared after a lot of analysis, collaboration and research. It must
align business understanding with a knowledge of relevant technology and
product options to present a practical vision for change.
Unless the project is initiated by management, it will be
necessary to gain management support even to incur the costs of the analysis,
collaboration and research that will be required to develop a business case.
You will need a business case for the business case development.
The first step to success is to develop a white
paper or vision statement that will sell the need for change to management. The
vision statement must:
describe the
problems and opportunities;
outline a realistic solution; and
describe the expected
benefits.
Commonly, it will include a
budget request to undertake the business case development. Development of the
vision statement involves relatively little work and risk, compared to later
tasks. If the vision statement is supported by management, the next step is to
develop a formal business case.
The aim is to build
up the project incrementally as you gather information and build support for
change within the organization. It is not necessary to ask management to make
big leaps of faith which they are unlikely to do. Instead, the initial steps
should be modest and always based on clear objectives for what is to be
achieved at each step of the process.
If management
does not support the vision statement, you will not have lost credibility or
wasted resources on ill-conceived product investigations or prototype
development. More likely you will have gained some recognition and planted a
seed that may germinate in the future when circumstances are more
favourable.
Review customer service & identify opportunities
The
key to understanding problems and opportunities needed for the vision statement
and business case is to understand the users of the documentation. After all,
why else is it created? Who needs documentation for your company's products or
services? Commonly, users include:
marketing department and sales
representatives;
trainers;
support desk;
customer users;
customer product maintenance personnel, software developers,
product installers, etc.
business partners such as product distributors and original
equipment manufacturers (OEMs) who may need to customize the documentation or
incorporate it with their own;
regulatory agencies.
Does current documentation really give each of these groups what
they need, in the form they need it and when they need it?
Is all this documentation produced in the most effective
way?
It is not uncommon to find that, say, training
documentation is prepared by a group that uses different software to the group
that prepares the user manuals. In such cases, it is almost certain there is
substantial overlap in this content.
It is possible
that some users will have printed documentation and others may have only web
access. Are these distinctions based on user needs or constraints imposed by
the way the content is created, such as file formats that cannot conveniently
be published to print or web outputs?
It is
necessary to analyse existing processes and talk to the listed user groups to
determine just which problems apply in each case. It may be useful to develop a
simple matrix of the current situation to understand the issues affecting each
user group. From this it will be possible to develop business requirements for
change and to see how the needs of different user groups are
related.
The analysis of users and their needs will
identify areas where existing services are deficient, either because there is
something wrong with the existing documentation, its method of production or
because user needs are not being addressed at all. These deficiencies are
opportunities. They can be turned into positive statements of goals for the
project. It is essential that the financial impact of these deficiencies is
assessed to gain an understanding of their relevant importance in the project.
The aim is to find substantial benefits that can be gained relatively quickly
as well as those that will require greater effort.
The vision statement
After the initial
user analysis, it should be possible to form a view whether there are
substantial opportunities for cost savings or revenue gain that can be
presented to management. The process for doing this is the vision
statement.
The vision statement
is the first step in a formal, incremental process. It is a pump priming or
boot strapping exercise to initiate the project with management. Its purpose is
to:
define the problem and goals to
reflect the shared understanding of all proponents of
change;
communicate the
need for change and the goals to management and others who may need to be
involved;
demonstrate that
there are potential material benefits that justify the expenditure of money and
allocation of personnel on a deeper
investigation.
The
vision statement should be quite brief, probably less than 10 pages. It should
describe:
the current situation and the
problems that exist with it;
the opportunities that may be available to cut costs and improve
revenue;
a broad indication
of the likely scale of the benefits that could be realized;
and
a possible strategy for
achieving those benefits.
It is important to state opportunities in
qualitative terms, such as reduce translation costs by 40%, or reduce the
volume of content for a particular set of manuals with common components by
30%. Obviously, there must be a reasonable basis for making those assessments.
Qualitative goals provide several important benefits:
They define clear success measures for the
project.
They keep people
focussed on the real objectives and can be used to test requirements along the
way. Will a supposed requirement contribute to the goal? If not, that
requirement can be left for another time.
They provide the foundation to quantify
benefits.
The vision statement should
be accompanied by an estimate for the work that is envisaged to verify the
strategy and develop a formal business case for the project.
The business case
Key components of the business case
include:
an analysis of the existing
circumstances, problems and opportunities (already developed in the vision
statement);
a realistic
description of how the opportunities can be realized (canvassed in the vision
statement but expanded here);
the projected financial benefits, covering expected revenue gains,
cost reductions and future costs avoided;
the projected costs of the proposed
system;
financial return
and benefits realization;
the risks and how they will be
managed.
A good business case will
involve considerable effort and research to understand the business
requirements and define the architecture for a technical solution. It is not
necessary to develop detailed technical requirements at this stage. That work
will be undertaken only when the business case is approved.
It is very likely that the business case should involve analytical
and technical input from external consultants who can advise on the options
available.
Benefits
The benefits of this approach are substantial.
Fundamentally, it is the only way to pursue a moderately complex project and
have any confidence that the results will be aligned to real business needs. In
particular:
It is the best way to ensure
that the correct level of funding is achieved.
It ensures that the project should have support
from the highest levels of management so that the project is not left in the
doldrums or summarily terminated when someone asks why are you doing this?
and you are unable to provide a business focussed answer.
It will provide clear success measures for the
project.
It will let you
plan the project and coordinate the involvement of different units within the
organization.
