Here is a question for Project Managers and Subject Matter Experts.
Have you ever been involved in planning a project where documentation is critical; if so, how did it go? Crucially, did the project achieve its aims of delivering ALL the documentation?
A collective failure of technical / process documentation projects is the lack of knowledge and expertise during the planning phases. If you ask a Technical Writer how long will it take to write one document, their reply will be – “I do not know”, because Technical and Process documentation depending on the project (PCI, Operations, ITIL) will have many different requirements and factors which delay the information gathering, the writing and review stages before sign-off.
The reality of a documentation project will be very different from the guesswork and theory. Many project managers and Subject Matter experts fail miserably because they fail to understand the lifecycle of a document. From the initial draft through various reviews and sign-off takes much longer than expected.
This is the likely reality: a 40-page document containing:
- VISIOs (2 or more)
- Process narratives (2 or more)
- Appendixes (2 or more)
Will amount to – give or take – at least 10 – 15 weeks of effort before it gets to the review stage. However, the more content and complex the document becomes, the longer it will take.
If you are wondering why it is worth noting that TWs working on large projects could have a personal list of up to twenty documents to complete and every document regarding size and content could be very different.
My first word of advice is this – If you have such a plan on the horizon, where the Technical / Process documentation is the primary focus – hire a Technical Writer to give guidance from the start of the project, NOT when the end date is in sight. The TW can highlight issues, risks and bottlenecks. You will also know what you can reasonably expect to achieve within the allocated time assigned to the project.
The Technical writers will need:
- a week (at least) to assimilate the project
- Time for training on any tools
- Subject Matter Experts (SMEs)
Add in contingencies for illnesses, holidays and unplanned absences due to personal reasons and the fact a TW could resign from the project at some point
If the budget and the timelines become fixed (in stone) with 50 documents to complete in a short period, then, consider producing Quality, rather than Quantity.
To ensure quality prioritise, or rank the documents to avoid inconsistency across the documentation set:
- Nice to have
- Not important
- Who will use them? Documents for external and internal users will require a different level of language
- What level of information and detail will the audience expect?
- Does the document need VISIOs?
- Travel: Will the TWs need to travel abroad or Nationally, if Yes, are they available to go and do they have current Passports/Visas?
- References: Identify any useable archived documentation.
- Reviews: decide who will review and who will sign off a document
- Scope: Could there be any changes which will add to, or change the scope of the project
Documentation projects fail due to:
- poor planning
- the lack of experience and
- not allowing enough time to complete the documentation.
Finally: If the success of the project depends on the documentation (Disaster Recovery Plan, PCI/DSS, BCP and ITIL) – why do PMs and SMEs allocate so much of the budget to non-documentation resources?