Technical Writing | Hire a Technical Writer sooner, rather than later

As a Technical Writer with over Twenty Years of experience, I need to address a problem which haunts documentation projects. I aim this at Project Managers who scope such projects as part of a more comprehensive project.

Have you ever planned a project (PCI, GDPR, ISO27001, ITIL, Policy and Process) 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.

If the PM does NOT know the difference between a written process, a documented plan, and the purpose of a policy and its processes, your project could be in trouble.

The planners do not understand the lifecycle of a document, from the initial draft through various reviews and sign-off. The process takes much longer than expected.

How long does it to write a document? My default answer is “I do not know”. Technical Policy 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 interviewing
    • opinions
    • the writing,
    • review stages,
    • amendments
    • opinions, and
    • sign-off.

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)

It will take at least 8 – 12 weeks of effort before 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 policy and process 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. To be safe, let’s say 24 months. If you have partially written documents, DO NOT expect timings to diminish to a few months. If the papers are scattered throughout various drives, the technical author must first attempt to get the documentation into a consistent state. That could take months of work.

Finally, there must be a management agreement to help the PM and TA find the resources to succeed. 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 when 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:

• • 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 resignations from the project. They happen.

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:

1. 1. Required
   2. Nice to have
   3. 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 affects nothing else on the project
  • W – I would like to have this requirement later, but delivery won’t be this time.

Additional Points

• • 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 size of the project

In summary,

Documentation projects fail due to:

• • poor planning
  • the lack of experience and
  • not allowing enough time to complete the documentation.

In contrast, documentation projects succeed due to:

• • excellent planning
  • understanding of documentation lifecycles
  • allowing enough time to complete the documentation.

Finally: If the project’s success 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?