Category: Policy documentation

Using Your Technical Authors as Strategists, Planners, and Consultants

Many businesses still misunderstand what a technical author can deliver.
They see a writer — not a strategist. A formatter, not a planner. A proofreader — not a consultant.

When used correctly, technical authors bring structure, compliance, and clarity to every stage of the information lifecycle. They turn documentation into a strategic enabler that supports ISO certification, ITSM frameworks, and information governance.

I didn’t gain this experience by taking on low-level contracts.
I built it by accepting complex, high-expectation assignments that demanded expertise — not routine.
Projects governed by ISO 27001, ISO 9001, PCI DSS, GDPR, and ITIL-aligned IT Service Management (ITSM) systems, where documentation wasn’t an afterthought, but a control in its own right.

From Document Writer to Information Strategist

Early in my career, I learned that a procedure is only as good as the system it supports.
As I advanced, I began designing those systems — integrating documentation with SharePoint, Asite, and enterprise knowledge bases to create traceable, auditable, and user-friendly environments.

That shift — from producing documents to architecting knowledge — is what separates an average writer from a documentation strategist.

Embedding ISO and Regulatory Frameworks

ISO 9001 — Quality Management

ISO 9001 demands consistency, clarity, and control. Technical authors design document templates, review workflows, and approval paths that prove process reliability. Well-structured documentation becomes part of the organisation’s quality evidence during internal and external audits.

ISO 27001 — Information Security

Under ISO 27001, documentation itself is a security control. Policies, risk registers, and incident procedures must align with the ISMS.
Experienced authors ensure classification, access permissions, and audit records are built into the documentation framework, not bolted on afterwards.

PCI DSS — Payment Card Security

PCI DSS requires clear operational documentation to evidence data protection. Authors provide traceable, reviewed, and controlled documents that survive audit scrutiny and demonstrate compliance with strict data-handling protocols.

GDPR — Data Protection and Privacy

GDPR compliance relies on transparency and accountability. Technical authors transform complex regulation into usable, plain-English policies: data-retention schedules, subject-access request processes, and breach-notification guides that staff can actually understand and apply.

Aligning Documentation with ITIL and ITSM

In IT environments, documentation underpins every ITIL and IT Service Management process:

      • Incident Management: Documenting escalation paths and resolution steps for service continuity.
      • Change Management: Recording change requests, approvals, and rollback plans to ensure traceability.
      • Problem Management: Capturing known errors and lessons learned to improve service quality.
      • Configuration & Asset Management: Maintaining controlled, versioned records of infrastructure and applications.
      • Service Continuity: Creating and maintaining recovery and resilience documentation aligned with ISO 22301.

A technical author versed in ITIL ensures that every process has the appropriate governance and documentation frameworks to meet compliance, audit, and service-delivery standards.

Aligning with Information Management and Document Control

Technical authors sit at the crossroads of Information Management (IM) and Document Control (DC) — translating policies into practice and ensuring that every piece of information has purpose, ownership, and lifecycle control.

      • In Information Management, authors define how data becomes information — creating naming conventions, metadata structures, taxonomies, and templates that keep repositories usable and compliant.
      • In Document Control, they understand versioning, approval hierarchies, baselining, and retention schedules — the mechanisms that give documentation its legal and operational validity.
      • Together, these functions ensure that knowledge doesn’t just exist, but is managed, retrievable, and auditable across departments, projects, and systems.

Where Information Management provides governance and Document Control enforces consistency, technical authors provide the structure and clarity that make both work.

The Modern Technical Author’s Toolkit

Today’s senior technical author is:

      • A strategist, aligning documentation with ISO, GDPR, ITIL, and corporate frameworks.
      • A planner, integrating documentation into project and service lifecycles.
      • A consultant, advising leadership on governance, information management, and document control.
      • A knowledge manager, ensuring content remains accurate, traceable, and secure.
      • A systems designer, configuring SharePoint or Asite to automate metadata, version control, and review cycles.

When you position your technical authors at this level, you gain more than documentation — you gain information assurance.

Experience Earned Through Expertise

Every project I’ve worked on — from ISO 9001 audits to 27001 ISMS documentation, from GDPR compliance to ITIL process alignment — has reinforced one truth:
Documentation is infrastructure.

It connects people, process, and technology.
It demonstrates governance and compliance.
And when managed properly, it becomes the backbone of every successful audit and transformation.

Final Thought

Technical authors who have grown through challenging environments understand how documentation supports the wider information ecosystem — policy, process, system, and control.

They close the gaps between communication and compliance, between information and evidence.

So before assigning your technical authors to “tidy up templates,” ask instead:

“Can this person help us align ISO, ITIL, and Information Management requirements into a single, coherent documentation strategy?”

If the answer is yes, you’re not hiring a writer.
You’re engaging a strategic partner in governance, compliance, and service excellence.

Technical Author: How Simple or Easy Is our job?

Let’s start with a question: what skills are essential for excelling in a technical author job?

      1. How many of you have technical authors on your team but do not know what they do?
      2. Have you tried to fit them in somewhere, or wanted to find them a role and failed?
      3. Have you written technical documentation for a client? If so, how did it go?

You may have given up trying to understand their role, thinking you should upskill them to meet your priorities. You might not grasp what technical authors contribute in their jobs and underestimate their potential.

Let’s examine the issue.

Managers often perceive technical authoring as “writing documents.” However, in reality, it is a complex, multidisciplinary role that requires expertise in several areas. One important area is understanding the technical author’s job in depth:

Understanding Technical Information

Technical authors translate complex concepts into clear, user-friendly documentation that is easy to understand. They engage with Subject Matter Experts (SMEs), interpret complex jargon, and ensure the accuracy of the information presented.

Structuring and Standardising Content

They do more than write. Technical writers need to work with formatting, templates, metadata, and indexing, which makes their job complex.

Managing Multiple Stakeholders and Reviews  

Technical authors liaise with stakeholders and end users, each with different priorities and expectations.

The process involves multiple reviews by experts, who underestimate the work required to improve the documents. This aspect is a key part of their jobs.

Adapting to Evolving Tools and Technologies  

From document management systems (DMS) like SharePoint, Confluence, and Asite to API documentation tools, technical authors must stay up-to-date with the constantly evolving industry standards. AI and automation are changing the nature of jobs and making technical writing more complex.

Balancing Quality with Deadlines  

Managers don’t always prioritise documentation, which means writers have to finish it quickly, but still produce great work.

They must work within strict project deadlines while ensuring accuracy, compliance, and usability. These demands highlight the challenges inherent in a technical author’s job.

Why do managers struggle with technical authors and their role? Let me know in the comments.

How to Create or Update Policy and Process Documentation

Discover how to plan, draft, and publish policies and processes that improve workflows, meet compliance, and support your organisation

Tweet
Pin
Share
0 Shares

Creating or updating policy and process documentation can feel daunting. By using the proper methods, you can make documents that are easy to read, useful, and compliant with regulations, assisting with daily work.

This guide shows you how to plan, write, and publish policies and processes, including schedules, resources, and necessary skills.

Step 1: Define the Scope and Plan

Key considerations:

    • Objectives: Are you meeting compliance, improving workflows, or clarifying roles?
    • Stakeholders: Engage department heads, compliance teams, and end users early.
    • Scope: Decide which policies and processes to create or update, prioritising business-critical areas.
    • Audit: Review existing documents for gaps, outdated content, or duplicates.

Estimated time:

    • Project planning: 1–2 weeks
    • Documentation audit: 2–4 weeks

Step 2: Research and Gather Data

Key considerations:

    • Compliance: Align with regulations and standards.
    • End users: Understand how staff will use the documentation.
    • Current practices: Observe workflows and interview subject matter experts (SMEs).
    • Technology: Ensure compatibility with tools such as Asite DMS or SharePoint.
    • Estimated time:
    • Research and interviews: 4–8 weeks
    • Process observation: 2–6 weeks

Step 3: Draft Policies and Processes

Key considerations:

    • Structure: Include purpose, scope, responsibilities, and procedures.
    • Clarity: Write in plain English. Avoid jargon unless necessary.
    • Visuals: Use workflow diagrams (e.g., Visio) for complex processes.
    • Version control: Track changes and manage document versions.
    • Estimated time:
    • Simple policy: 2–4 hours per document
    • Complex policy: 2–3 days with SME review
    • Process mapping: 3–7 days

Step 4: Review and Validate

Key considerations:

    • SME review: Check accuracy and compliance.
    • Testing: Pilot with a sample group of users.
    • Refinement: Incorporate feedback and re-draft as needed.
    • Estimated time:
    • Review cycle: 1–2 weeks per draft
    • Pilot testing: 2–4 weeks

Step 5: Finalise and Publish

    • Key considerations:
    • Approval: Secure sign-off from leadership.
    • Formats: Publish in user-friendly formats (PDF, intranet, or DMS).
    • Training: Provide user guides or training sessions to support adoption.
    • Estimated time:
    • Formatting and approval: 1–2 weeks
    • Training materials: 2–4 weeks

Project Timelines

    • New documentation: 3–6 months (medium complexity)
    • Updating documentation: 2–4 months

Resources Needed

    • Technical authors: Skilled in plain English writing and structuring documents
    • SMEs: Knowledgeable in compliance, operations, and workflows
    • Tools: Document management systems (Asite, SharePoint) and process mapping tools (Visio)
    • Reviewers: Stakeholders to provide input and approvals
    • Training resources: Guides and sessions to drive adoption

Expertise Required

    • Writing and editing skills
    • Interview techniques to gather SME knowledge
    • Regulatory and compliance awareness
    • Process mapping and visualisation
    • Change management experience

Final Thoughts

Policy and process documentation reduces risk, improves efficiency, and ensures compliance. By following these steps—plan, research, draft, review, and publish—you can create documentation that staff will actually use and trust.

 

Process, Procedure, Work Instruction, Plan, Strategy and Standards — Know the Difference

Clear documentation depends on understanding the difference between processes, procedures, work instructions, plans, strategies and standards. This article explains how each fits into a structured documentation framework.

Tweet
Pin1
Share
1 Shares

Many organisations use the terms process, procedure, work instruction, plan, and strategy interchangeably. They are not the same. This article explains the key points to help clarify these differences.

Confusion between these terms leads to poor documentation, unclear responsibilities, and inconsistent delivery.

If you work in technical authoring, information management, or governance, understanding the difference is essential.

A good documentation framework clearly separates these elements and ensures people know what they must do and why.

What is a process?

A process is a set of interrelated activities that turn inputs into outputs.

A process describes a complete business activity from beginning to end.

You must:

      • Learn the process
      • Understand why it exists
      • Perform it end-to-end

A process is:

      • A high-level description of work
      • Cross-functional
      • Ongoing and repeatable
      • Updated periodically
      • Supported by policies and standards

A process answers the question:

“How does the business operate?”

What is a procedure?

A procedure provides more detail than a process but less detail than a work instruction.

It explains how to perform sequential tasks to achieve a defined outcome.

A procedure usually:

      • Follows a logical sequence
      • Has an obvious start and finish
      • Can be completed in one working session
      • Describes responsibilities

A procedure answers:

“How do we complete this activity?”

What are work instructions?

Work Instructions (WI) describe exactly how to perform a specific task.

They provide step-by-step guidance with no ambiguity.

A work instruction:

      • Describes one task
      • Contains detailed steps
      • May include screenshots or diagrams
      • Removes interpretation

Work instructions answer:

“How do I do this task?”

What is a plan?

A plan is not a process.

Many organisations confuse the two.

A management plan describes what will be done, not how work is performed.

A plan typically includes:

    • Objectives
    • Resource allocation
    • Timescales
    • Responsibilities
    • Risk considerations
    • Contingencies

A plan shows how an organisation will move from Point A to Point B.

It supports the strategy by describing how resources will achieve the aim.

A plan answers:

“What are we going to do?”

What is a strategy?

A strategy explains how an organisation will move from Point A to Point B.

It defines direction rather than detailed actions.

A strategy typically includes:

      • Current position (Point A)
      • Desired position (Point B)
      • Problems and constraints
      • Opportunities
      • Tools and approaches
      • Decision principles

A strategy considers obstacles and risks that may slow progress.

Strategy answers:

“Where are we going and why?”

Your strategy defines what you want to achieve.

Understanding the difference between a strategy and a plan allows organisations to make better decisions.

What is a standard?

Standards define mandatory rules and behaviours.

They support policies and ensure consistency across the organisation.

Standards are:

      • Mandatory
      • Enforceable
      • Organisation-wide
      • Consistent
      • Long-term

Define expected behaviour, for example:

      • Email signatures
      • Naming conventions
      • Approved hardware and software
      • Document templates
      • Security controls

Must be enforced to be effective.

This applies equally to policies and standards.

Why does this matter?

When organisations confuse these terms, documentation becomes chaotic:

      • Plans get mistaken for processes
      • Procedures become incomplete
      • Work instructions disappear
      • Strategies become wishlists
      • Standards are ignored
      • Clear documentation separates these layers and ensures:
      • Consistent delivery
      • Clear responsibilities
      • Better governance
      • Easier audits
      • Stronger information management

This structure is the foundation of a well-run documentation system.

Content and Documents | How Can I help you?

In the aftermath of Coronavirus, many managers may know they have documentation projects in the pipeline and, on their mind, is hiring a technical author. As a contract Technical Author with 20 years plus experience, what can I offer you?

What type of documentation will your project need?

With the documentation, I would advise you NOT to delay even now and start any discovery phase to identify which titles you need to prepare.

How can I make your project run with more ease?

I have a vast collection of generic documentation covering PCI, ISO27001, GDPR, ITIL. Hence, with some tweaks and by understanding your requirements, my generic documentation can be tweaked to suit your company’s needs, which will save time and money.

Compliance projects

Compliance projects generate more documentation than managers expect. If you have not already performed a discovery or due diligence phase, you could have up to 60 titles to write ranked in order of importance.

  • Payment Cards Industry (PCI)
  • ISO27001
  • ITIL and ITSM Policy and process documentation

Confluence and SharePoint

Do you use either confluence or SharePoint, or both?

Have you lost control of the content/documentation?

Has the structure in Confluence been overridden by numerous spaces that are no longer valid, filled with legacy content and no ownership?

Poorly written content and documents can hamper productivity and lead to mistakes. You may need an expert eye to look over your content and documents and identify what is no longer needed and seek to slim down the information in either.

Transformation

Are you about to start a transformation project and have discovered the documentation has no value? Stress not. With help from SME’s and a series of interviews, the documentation will soon be underway. I wrote a booklet on such projects. Read it. To help start the technical documentation, I have the following templates:

  • Operating templates
  • Installation guides
  • Profile document
  • Technical procedures for management

Disaster Recovery and Business Continuity

I have a collection of templates that can help get a plan up and running after consulting with your staff.

Call Me 07534 222517

Email: twriter201@gmail.com

Hire a Technical Author sooner, rather than later

Documentation projects rarely fail at the writing stage—they fail during planning. Poor scoping, unrealistic timelines, and lack of technical author input lead to delays, rising costs, and incomplete deliverables. Here’s how to avoid it.

Tweet
Pin
Share
0 Shares

Documentation project planning

As a technical writer with over twenty years of experience, I have seen project managers repeat the same mistakes across multiple projects. The root cause points to poor documentation planning. It is a problem that often goes unnoticed until a professional steps in and identifies it.

If you have delivered a project involving PCI, GDPR, ISO27001, ITIL, or policy and process documentation, ask yourself:

Did the project deliver all the required documentation?
If not, do you know why?

In my experience, the failure begins in the planning stages.

The First Mistake: Not Consulting a Technical Author Early

Did you speak to a technical author for a realistic appraisal?

If the answer is no, there lies your answer.

Managers treat documentation as a downstream activity. Something to complete once systems, processes, or controls are in place.

That assumption is wrong. Documentation is a structured discipline involving:

      • discovery
      • analysis
      • stakeholder engagement
      • controlled writing
      • review cycles
      • approval workflows

Without this understanding, planning becomes guesswork.

The Second Mistake: Underestimating Time and Budget

Another common issue:

The budget is short, and the timelines are optimistic.

Project managers frequently underestimate the effort required to produce controlled documentation.

A simple question often arises:

“How long does it take to write a document?”

The honest answer is:

“It depends.”

Because writing is only one part of the process.

What Actually Takes Time in Documentation Projects

For a typical documentation project, the effort is distributed across:

      • Information gathering
      • SME interviews
      • Conflicting opinions and interpretations
      • Writing and structuring
      • Multiple review stages
      • Amendments and rework
      • Final approval and sign-off

Here’s a realistic outcome to consider:

      • 30-page process document
      • 3+ Visio diagrams (10–30 steps each)
      • 3+ process narratives
      • 2+ appendices

Expected effort: 8–12 weeks before review.

That is one document.

Scaling the Problem: Compliance Projects

Compliance frameworks significantly increase the scope.

If starting from scratch:

      • 60+ documents is not unusual
      • 12–18 months of work is typical
      • 24 months is a safer estimate

If documentation already exists, fragmented across drives, emails, and legacy systems: Do not expect timelines to reduce; the first phase becomes:

      • consolidation
      • standardisation
      • validation

This alone can take months.

The Knowledge Gap in Planning

A major contributor to failure is a lack of understanding of:

      • The difference between a policy, a process, and plan
      • The document lifecycle (draft → review → approval → maintenance)
      • The complexity of controlled documentation environments

Delays are inevitable when managers cannot understand these fundamentals during planning.

Why do documentation projects fail?

Documentation projects typically fail due to:

      • Poor planning
      • Lack of documentation expertise
      • Unrealistic timelines
      • Insufficient budget
      • No defined ownership or review structure

Why Documentation Projects Succeed

Successful projects have:

      • Early involvement of a technical writer
      • Clear understanding of the documentation lifecycle
      • Realistic timelines based on effort
      • Defined ownership and governance
      • Structured review and approval processes

Hire a Technical Writer at the Start — Not the End

A common mistake is hiring a technical writer when:

      • deadlines are approaching
      • Documentation is incomplete
      • Exhausted budgets
      • At that point, recovery is expensive.

A technical writer engaged at the start can:

      • Identify risks early
      • define a realistic scope
      • structure documentation outputs
      • manage stakeholder expectations
      • prevent rework

Resourcing Considerations

Technical writers require:

      • Time to understand the project
      • Training on tools and environments
      • Access to SMEs
      • Availability for review cycles

You must also account for:

      • holidays
      • illness
      • unplanned absences
      • staff turnover
      • These are not exceptions. They are normal project variables.

Quality vs. Quantity: Use Prioritisation

When timelines are tight, prioritise deliveries using the MoSCoW Method:

      • Must have
      • Should have
      • Could have
      • Won’t have (this time)

Or classify documents as:

      • Required
      • Nice to have
      • Not important

Focus on delivering usable, controlled documentation, not volume.

Additional Planning Factors Often Ignored

      • Travel: Will the technical writer need to travel?
      • What can you reuse?
      • Review structure: Who reviews and who signs off?
      • Scope changes: How to control expansion?

Final Thought

When your project requires documentation, why is so much of the budget allocated to everything except documentation?

Documentation is not an afterthought. It is the mechanism that explains, controls, and sustains your operations.

Remove it—or underfund it—and the cost will surface later.

Usually, when it matters most.