As early as possible would be the ideal answer.
It’s been said for decades and ignored for as long.
If you have and editorial plan that is compatible with a product plan, then both the product and its documentation can be written in the same rhythm and probably even with the same agile procedure. This may frighten product or project managers, if they think it augments redundancy or overhead. If agile structures work for software writing, why shouldn’t they work for user documentation?
So once again…
Start as early as possible.
Define the editorial objectives
Determine who is addressed by the documentation.
Are there several levels of user? If so, cater for them independently.
Map out what parts of the software need to be covered. Yes this is part of an editorial plan.
Define the key elements of the writing style.
Identify the key contributors
All product stakeholders can be contributors.
- One the one hand, a product owner or manager knows why he prescribed his software.
- Developers know the details.
- Support teams know what problems user face.
Get them working together in the same project plan and software.
Plan the editorial stages
Distinguish between in-situ contextual documentation and other forms.
Contextual documentation should be written in collaboration mode by developers and writers. This combination avoids double errors – the developer talking to himself – the writer misunderstanding and doing overkill.
Other forms of documentation are identifiable when deal with in-situ documentation.
The documentation process should allow for validating their real utility.
Plan the re-reading and validation phases
Software is tested in general before release.
This should also be the case of documentation.
Release documentation with the product and upgrade in the same rhythm
Alpha and beta testing should include documentation in the same state. It should be handled with the same criteria.
Who should write?
Different documentation types can have different contributors. Most software editors may not have dedicated technical writer teams. In this context:
- Configuration documentation can easily be written by techies.
- Procedures can be defined by product owners.
- Getting started topics can be described by support teams or trainers.
- Frequently asked questions can be suggested and captured by a support team.
If you have technical writers, they can drive and contribute to the process. If you don’t, maybe you can have them fine-tine the contents from time to time on a contractual basis.