As stated in the document "Writing and Programming - Next of Kin", writing isn't all that different from making efficient software. The essentials can be boiled down to:
This is not all that different from writing your typical requirements and design-documents.
All of the above seems obvious, but too often people just knock out a piece of documentation without paying too much attention to target audience, outline or language usage. To prove this point, here's something I once overheard from one of my developer colleagues who was asked out for lunch:
"Yeah, I'll be with you shortly - I just have to write up some documentation for this thing..."
In the ears of a writer this makes as much sense as the following would to a programmer:
"Yeah, I'll meet you there - I just have to code this workflow engine from scratch..."
Now that you've got the target audience, document structure and style of language clear, it's time to start writing. If you've followed the steps above, writing the document shouldn't be too hard - just as coding a piece software isn't all that hard if you've clearly defined the requirements and design.
Exactly how hard this part is and how well the thing turns out depends on your writing experience and your natural talent for writing. But even without talent and with little experience, a thorough preparation should ensure a reasonable document.
Once you're done with your first draft of the document you need to make sure that the content is coherent.
Working on a project for weeks or months tends to make you blind to the fact that other people live different lives than yours. Not everyone can match your level of knowledge on the subject you're writing about, and you need to make sure that the text doesn't build on top of knowledge that it doesn't provide - if there are any prerequisites to understand the document, list them in the very beginning.
You also want to make sure that your document answers all questions it might rise. Squeeze your brain to figure out which questions people could possibly ask after reading the document. Have someone unfamiliar with the subject read the text to drain it for all open questions. Then implement the answers in the document.
After passing the tests in the previous section, you can start looking at the language itself. This is where you can make a difference and make your personal voice heard. This is also the hardest part.
You can bury a totally exciting point in language so boring that people never get it. Do your part of the job and ensure that your language is lively and interesting - by doing so you make the readers' part of the job so much easier.
Since you know everything about the subject that you're writing about, the biggest danger is that you see through the language and only care about getting the facts right. This is no crime but there's no reason that your text shouldn't be as digestible as possible. This requires some focus on the language itself. Take a look at this quote I once found in a piece of documentation for a workflow package:
The text explains what the workflow package does, so everything is fine. Or is it? The text doesn't really qualify as very interesting and the only truly remarkable thing about it is that it contains a sentence of more than 350 characters. The latter is impressing but not likely to enhance readability.
A little editing turned the text into this:
Wow, what a difference. Not only are the sentences more well-balanced but now we have a metaphor, which always makes a text lively and digestible. This metaphor even makes explanation of all aspects of the workflow engine easier since there now is an easily perceptible picture to relate to (the 'old-fashioned' office).
Mine your text for opportunities to clean up and rephrase into something more interesting than just a grammatical correct presentation of facts.
Edit your document and have it edited by others as many times as you can possibly bear. You'll meet a natural limit where you just hate the text more than anything - this would be a good time to put it away for a while.
Here's a couple of practical hints to how you can work with your text:
And never forget that everyone needs an editor.
You can subscribe to a low-volume newsletter that will notify you when I publish something new around here.