Document – and do it well

Many start up firms as well as fast growing companies (especially in internet and technology sector) evolve pretty quickly, working on several projects at the same time, developing new solutions, tap into new markets. All resources are pooled towards these strategies, as those new solutions will eventually bring in the money to pay for the entire idea. This means that the task of documenting things, put them down to writing is often overlooked, undervalued, and left for somebody else to do, or for the never-coming tomorrow.

“We haven’t decided on the exact format, so we don’t want to document yet to avoid having to do it all over again”.

“Well there is no documentation, because we have worked with this format forever, and everybody knows what it envolves.”

“It is too time consuming, because we are constantly improving our system, so documenting things doesn’t make sense to us.”

These are my favorite reasons for not getting the documentation right. However there are palpable arguments for drawing up and elaborating a concise basic documentation:

• The sales and marketing department knows exactly what features the products/services offered are actually implemented already.
• If the chief software developer and the database guru decide to take a sabbatical, the main features of all products/services can easily be reconstructed.
• All departments working along the value chain know the specificities and will use the tools correctly. Not because they have done it like this forever, but because they know for sure how it works.
• New team members on board can be trained much quicker and always can get back to the documentation if there is further doubt.

To fulfill these purposes, your company does not need a full-fledged, super detailed documentation. However, you should commit resources to getting the basic documentation done and review it every 4 weeks (if you are still working on the project) or every 6 month (if there are only minor or no changes expected). Following up on the documentation, adding new features and changing stuff is done much quicker once a reliable first version is available.

Thus, this basic documentation has to respect the following guidelines:

• Use clear and simple language. Basic documentation should be understandable for everybody in the company, independent of the department, technical background, job role. Everybody should be able to understand what the product/module/process stands for.
• Describe the results, not the technical specificities. In contrats to technical specs, the basic documentation should be focussed on describing the what the product is actually doing. For example: “The google keyword tool offers a selection of popular search queries related to the user’s interest. The information is gathered through the google search engine itself and aggregated in the keyword tool.” No need to add the exact algorithm used by google, nor how where and what the queries are gathered. The main idea is enough to ensure that everybody understands what it is about.
• Highlight important details that influence the usage of the product. The google keyword tool yields different results, whether you query for documentation or documentations. These differences are important, so they need to be adressed in the basic documentation. Otherwise somebody along the way will forget to query for the different spellings and you might loose out on business because you didn’t include that crucial keyword.

Not everybody likes documenting processes and products. And for some it is easier than for others. Try to find somebody in your company who understands the big picture, while still paying attention to the details, and is able to write a clearly understandable outline. This person should talk to the developers, to the departments using the process/product, as well as to sales and marketing to understand their main concerns. That way she will be able to take into account the technical specificities, while assessing which parts are most crucial for the users within the company.

Finally, the documentation should be reviewed quickly by one person from each department to a) find misinterpretations and b) find gaps in the documentation which only appear once something is committed to writing.

The final version should be distributed to everybody involved with the product/process and stored in an easily accessible way. As it draws the bold lines of all products/processes no company secrets should be at immediate risk, however the quality of work within the departments should increase as soon as everybody knows what they work with.

And don’t forget to make sure that your people read the documentation!

• quality