Improving the effectiveness of information

A couple of weeks ago I started really enthusiastic with structuring the product requirements and product specifications of my customer's products. The goal of my work was to create a knowledge bank in which the audience can see both the product requirements and the relevant specifications next to each other. Last week I have finished the knowledge bank and presented it to the product architects. What did I learn from this project? Don't use your documentation project to restructure the whole organization First of all: it is impossible to capture the whole world in just one set of models. When you have to think of a documentation solution for a whole organization, it is tempting to restructure everything into one consistent overall structure. The truth is that in an ideal world this would be an excellent solution. In the real world you can't just change everything to get the desired result. Make a series of models for every single department or organizational unit that has

In my article "How knowledge becomes usable" - published in the Winter edition of Communicator - I explain how you can incorporate knowledge-driven design in information products. The Communicator is the quarterly journal of the Institute of Scientific and Technical Communicators (ISTC). The article is a follow-up on my presentation at the ISTC Conference 2007 in Liverpool. If you are a member or a subscriber of Communicator, you automatically receive this issue. Otherwise, if there is something of interest to you, contact the ISTC Office to purchase a copy. The ISTC is the largest UK-based society for professional communicators. If you are a technical communicator and working in the UK - or Europe in general - I can strongly recommend membership of the ISTC. Look for more information on their website: www.istc.org.uk .

I mentioned in my last article of 2007, that as a technical writer you can expect to be asked for several kinds of documentation within your organization. Recently I started to structure the product requirements and product specifications of my customer's products. The intended audience consists of the product manager and product architects on the one hand and the developers on the other hand. The goal of my work is to create a knowledge bank in which the audience can see both the product requirements and the relevant specifications next to each other. At this moment there are two types of documents: A functional requirements document: This is a 27 pages long Word document, including some illustrations. It has a thematical structure. This document is written and edited by two product architects. Component design documents: These are detailed functional and technical descriptions of parts of the product, first written by developers and then edited by two functional designers. The co