As a Technical Writer with over Twenty Years of experience, I have a question for Project Manager. Have you ever planned a project (PCI, GDPR, ISO27001, ITIL) where documentation is critical; if so, how did it go? Crucially, did the project deliver ALL the documentation? If not – do you know why the plan failed?
First: Did you speak to a Technical Writer for a realistic appraisal of the expected outcomes?
Second: was your budget a few pennies short?
A collective failure of technical / process documentation projects is the lack of knowledge and expertise during the planning and discovery phases. Many project managers do NOT grasp the reality of a documentation project.
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.
If the PM does NOT know the difference between a written process, a documented plan, and the purpose of a policy your project could be in trouble.
How long to write a document? My default answer is “I do not know”. Technical and process documentation depending on the project (PCI, GDPR, Operations, ITIL) will have many requirements and factors which delay the following stages:
- the information gathering,
- the writing,
- review stages, and
The likely reality of writing a 30-page A4 process 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 take at least 8 – 12 weeks of effort before reaching the review stage. My advice is not to plan such a project without professional help.
Compliance projects such as PCI and GDPR generate a lot of documentation. If you are starting from scratch, the list of required documents could exceed 60 or more. In timing terms you are looking at 12/18 months of work or more. If you have partially written documents, DO NOT expect timings to diminish to a few months. Your project faces a lengthy overhaul as a technical author will attempt to get the documents into a consistent state. Finally, to succeed there must be management buy in. Without t the TA will struggle to muster the help. Any failures will multiply costs.
Hire a Technical Writer
My advice is this – If you have a project that requires documentation, hire a Technical Writer, not a Business Analyst, for advice from the start of the project, NOT when the end date is in sight and the budget is running out. The TW can highlight issues, risks, and bottlenecks and help you manage expectations 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, 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 produce quality, rather than quantity.
To ensure quality, rank the documents across the 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.
- Travel: Will the TWs need to travel abroad or Nationally.
- 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?