As a Technical Writer with over Twenty Years of experience, I have a question for Project Managers and Subject Matter Experts. Have you ever been involved in planning a project (PCI, GDPR, ISO27001, ITIL) where documentation is critical; if so, how did it go? Crucially, did the project achieve its aims of delivering ALL the documentation? If not – do you know why the plan failed? It could be that you were unable to hire Hire a Technical Writer for advice and guidance.
Why Hire a Technical Writer?
A collective failure of technical / process documentation projects is the lack of knowledge and expertise during the planning and discovery phases. Many project managers and Subject Matter experts fail to grasp the reality of a documentation project. Many projects fail miserably because the planners do not understand the lifecycle of a document. From the initial draft through various reviews and sign-off takes much longer than expected. I regret to say I have met PMs and Consultants that do NOT know the difference between a written process a documented plan and the purpose of the policy. If that is the case, your project could be in trouble.
How long to write a document?
If you ask a Technical Writer how long will it take to write one document, their reply will be – “I do not know”. Technical and Process documentation depending on the project (PCI, GDPR, Operations, ITIL) will have many different requirements and factors which delay the information gathering, the writing and review stages before sign-off.
The likely reality of writing a 30-page document containing:
- VISIOs (3 or more) comprising between 10 to 30 steps
- Process narratives (3 or more) of between 10 to 30 steps
- Appendixes (2 or more)
Will amount to – give or take – at least 8 – 12 weeks of effort before it gets to the review stage. However, the more content the document contains and the more complicated it becomes, the longer it will take.
My advice is not to plan such a project without professional help.
If you are wondering why it takes so long – it is worth noting that compliance projects such as PCI and GDPR generate a lot of documentation. TWs working on large projects could be managing a list of more than twenty documents and every document regarding size and content could be very different.
Hire a Technical Writer
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, not a Business Analyst, 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
- access to 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 multiple 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
Or use The MoSCoW method.
- M – Must have this requirement to meet the business needs
- S – Should have this requirement if possible, but project success does not rely on it
- C – Could have this requirement if it does not affect anything else on the project
- W – Would like to have this requirement later, but delivery won’t be this time
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?