Here is a traditionally recommended general sequence of the 29 steps for a documentation project:

  1. Discuss the need for the document with your client.
  2. Determine the purpose and objectives of the document.
  3. Talk to intended users of the documents.
  4. Profile the users’ information needs.
  5. Prepare an outline of the planned contents of the documents
  6. Design the layout of the document.
  7. Plan the online version of the document.
  8. Prepare style guidelines or a style sheet.
  9. Prepare a sample section of the document (a prototype).
  10. Estimate time and costs to write and produce the document.
  11. Schedule the project.
  12. Review document plan with client and get approval.
  13. Gather all relevant background information.
  14. Conduct detailed interviews with subject matter experts.
  15. Draft sections of the document.
  16. Prepare graphics.
  17. Format (layout) draft sections of the document.
  18. Edit draft sections.
  19. Review draft sections with subject experts and revise.
  20. Review draft sections with the project team and revise.
  21. Test accuracy and completeness of critical sections of the document.
  22. Prepare alphabetical index.
  23. Final edit and proofread.
  24. Review the completed document with the project team and get approval to print.
  25. Prepare the online version of the document.
  26. Design and print covers.
  27. Prepare printing specifications and coordinate printing.
  28. Distribute the printed document.
  29. Get feedback from the final users of the document on its effectiveness.

Lots of situations might call for changing this sequence a bit. Some software documentation is written for developers or even contributed by developers, such as docs for API or SDK. Following the philosophy of Docs-as-code, the document will be written in Markdown and published on a website; it may not need a print-out version like PDF. As a result, the procedure will change accordingly.