|
Vesa Purho
Research Analyst, Information Design, Nokia
When documentation is a product, for example, a newsletter or
a magazine, then you should handle its development as you would handle any other
product development. You should do market analysis, create marketing strategies,
and try to create a need for the documentation, even in multiple copies and in
many mediums.
However, if documentation is not the main product that your
company sells, the situation is different. Then, there are different options
depending on how you view the role of documentation and whether it brings in any
revenue that is kept as a separate account in the bookkeeping.
Documentation Brings Revenue
If you view documentation, or some of it, as an additional
service to your customers and the cost and revenue are kept separate in
bookkeeping, you should handle the documentation development as if it were a
separate product. Naturally, your market analysis and marketing efforts must be
tied to the product the documentation is for, but you should be able to cover
all the cost of developing the documentation sooner or later by its sales. To
create more revenue, you also have to try to create a need for the users to use
the documentation, which usually leads to experimenting with new media formats
and delivery channels.
When developing documentation that brings revenue, market
analysis and financial analysis (return on investment, payback time, and so on)
are very important. Measuring the success of the new information product is easy
because the sales measure whether the users want and need the documentation.
Even if documentation is not bringing visible revenue to the
company, you may view it as a separate product, but you may be heading for
trouble if you develop the documentation accordingly. You may end up producing
cool multimedia presentations that are not actually needed by the users, and
they only get frustrated because they don't find the information that they
actually want when using the product. So you have wasted money and reduced
customer satisfaction at the same time, which won't make your managers very
happy.
Documentation is viewed as Part of a Product
If documentation is bundled with the product, meaning that the
cost of documentation is incorporated into the price of the product, then you
should think of the documentation as a tool that supports the users of the main
product. You should aim all development of the documentation at providing better
support for the users to make their work easier and not try to create a need for
the documentation. Naturally, some new technologies and media can be a solution
for providing better support, but if they don't help provide better support, you
should not invest in them.
Estimating the impact on the company revenue of documentation
that is part of a product is far more difficult than if the documentation
brought in its own revenue because proving that the sales of the product has
increased because of better documentation is usually difficult; exceptions to
this do exist. Also, measuring the success of the documentation in financial
terms by following up the development of end-user support and determining
whether end-user support decreases because of better documentation can sometimes
be difficult.
What you can do is measure customer satisfaction with the
product and documentation, but how do you convert that into money that covers
the development activities? Can you actually calculate ROI in these situations
and should you? What kind of development activities can you initiate if you
cannot prove that the costs will be covered?
The answer to the second question is no; you cannot usually
calculate ROI effectively if the return is not money that you can directly see
and point out to be a result of your activities but is instead something less
tangible like customer satisfaction. Adrian Mello points this out in his
article,
"Why ROI can sometimes lie,"
on ZDNet Tech Update.
The answer to the third question is that you should only
initiate development projects that are based on actual user needs. However, you
should note that users don't always know what they need, For example, you may
not get a direct requirement for providing an e-learning course, but if the
customers complain about having to send their staff to off-site training or
about the difficulty of matching their timetables to course schedules, they may
actually need an e-learning course. Naturally, you need to validate your
proposed solutions with the users to find out whether they accept them or not.
Finally, I want to wish you all a Happy New Year 2002!
This article is the personal opinion of the author and does
not necessarily reflect the opinion or practice of Nokia.
|
