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.