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.

IT Audits: a Technical Authoring view

IT Audits: A technical author’s view from the front line. I have worked on several projects, including an audit of a company’s IT ahead of a migration from one data centre to another. In three cases, no documentation existed; in the fourth, documentation was scattered around in various places.

IT Audits

IT Audits: A technical author’s view from the front line. I have worked on several projects, including an audit of a company’s IT ahead of a migration from one data centre to another. In three cases, no documentation existed; in the fourth, documentation was scattered around in various places.

Data Centre migrations

An IT audit focusing on a data centre migration project aims to ensure the process is well-planned and executed to minimise risks, guarantee operations and data integrity continuity, and adhere to relevant standards and regulations. This article introduces the data centre migration audit concept and what it entails.

Documentation Required

The project will require several documentation types. As the project rolls on,  the project managers will develop their documents, such as progress spreadsheets. As a Technical Author, our focus is on the following documentation:

Profile documents – these are recommended if there is little to no documentation in existence. These documents contain high-level information. You will need one per server and list all the information such as users, dependencies, DR requirements, what it hosts, data flows In/Out and much more. I can supply a full list on request.

Operating Documents: These contain Profile information plus more granular information. The receiving team uses them as comprehensive information backup and must be stored in an accessible location.

Installation Documents – these provide valuable installation processes using the company’s configurations. These must also be stored in an accessible location.

Knowledge Transfer – to ensure everyone reads from the same page, collects knowledge from SMEs and shares it in an accessible location.

Purpose of the IT Audit in Data Centre Migration

  • Risk Assessment: To identify and assess risks associated with the migration, including:
      • data loss,
      • downtime,
      • security vulnerabilities, and
      • compliance issues.
  • Process Evaluation: To ensure that the migration process follows
      • organisational policies,
      • including project management,
      • change management, and
      • quality assurance.
  • Verification of Data Integrity and Security: To verify:
      • data integrity
      • implement security measures for data protection
  • Compliance Check: To verify adherence to relevant regulations and standards (e.g., GDPR, HIPAA, ISO/IEC 27001) that may impact the migration process.
  • Post-Migration Review: To evaluate the success of the migration in terms of meeting its objectives, including:
    • performance benchmarks,
    • cost-effectiveness, and
    • achieving planned benefits.

Critical Components of the Audit Process

  1. Pre-Migration Planning: Evaluating the thoroughness of the migration strategy, including:
    • assessing the current data centre’s architecture,
    • the migration’s Scope, and
    • the target environment’s readiness.
  1. Implementation Review: Analysing the execution of the migration to ensure it aligns with the following:
    • planned procedures,
    • project timelines, and
    • This includes reviewing the technical approaches, such as
    • data replication,
    • network reconfiguration, and
    • application migration strategies.
  1. Security Measures: Assessing the security protocols implemented before, during, and after the migration to safeguard data and infrastructure. This encompasses access controls, encryption, and security monitoring tools.
  2. Data Integrity Verification: Ensuring that data transferred during the migration is accurate, complete, and unchanged. Techniques such as checksum verification and data reconciliation are part of this process.
  3. Business Continuity and Disaster Recovery (BC/DR) Planning: Reviewing the effectiveness of BC/DR plans in the context of the migration, including the ability to recover data and maintain operations in the event of a failure.
  4. Post-Migration Validation: Conducting a thorough review after the migration to ensure that all systems operate as expected in the new environment. This includes performance testing, functionality verification, and ensuring that you achieve the migration objectives.
  5. Documentation and Reporting: Reviewing the completeness and accuracy of documentation related to the migration process, including planning documents, execution records, and post-migration evaluations. The audit will conclude with a detailed report highlighting findings, recommendations, and any identified issues.

Managing the Audit Process

    • Stakeholder Engagement: Involving critical stakeholders throughout the audit to ensure alignment and address concerns.
    • Use of Tools and Technologies: Leveraging specialised tools for data migration, security assessment, and project management to facilitate a thorough audit.
    • Expertise: Engaging with IT auditors with experience in data centre migrations and understanding the technical, operational, and compliance aspects of such projects.

Preparing for an IT audit involves a comprehensive review and documentation of your organisation’s IT infrastructure, policies, and procedures. The goal is to ensure your IT environment aligns with best practices, legal and regulatory requirements, and industry standards. Here’s a step-by-step guide on how to prepare for an IT audit focusing on documenting the network, servers, data flows, and disaster recovery (DR) outlines:

Understand the Audit Scope and Objectives

    • Identify the Type of Audit: an internal or external audit and the standards or guiding regulations (e.g., ISO/IEC 27001, GDPR, HIPAA).
    • Define the Scope, including specific systems, processes, or locations.

Assemble a Core Team

    • Select a diverse team of subject matter experts (SMEs) from different areas of your IT environment (network, server administration, data management, security, disaster recovery).
    • Designate a project manager with strong organisational and communication skills to lead the documentation effort.
    • Overseas Infrastructure: If the company has European offices, make contingencies for language barriers.

Designate a Point of Contact (POC)

    • Choose a POC fluent in English and possibly other languages spoken by team members to manage all communications effectively.
    • This person should have a good technical understanding and excellent communication skills to bridge language or technical gaps.

Consider Direct Meetings

    • If feasible, arrange for technical authors, or project leads to meet with overseas colleagues in person.
    • Direct interactions can foster better understanding, clear up ambiguities, and build stronger team cohesion.

Kickoff Meeting

    • Hold a kickoff meeting to outline the documentation project’s goals, process, and importance.
    • Use clear, simple language and visual aids to ensure understanding across language barriers.
    • Discuss the need to create a high-level profile document.

Document Collaboration

    • Utilise collaborative tools like shared documents, diagrams, and project management software that support comments and revisions.
    • Ensure the tools chosen are accessible and user-friendly for team members with varying technical expertise and language proficiency levels.

Collect Basic Information

Start by collecting high-level information about the IT infrastructure to create the profile document:

    • Network architecture: Outline the basic network design, including principal components like routers, switches, firewalls, and connectivity layout.
    • Servers and devices: List critical servers, their roles (e.g., web server, database server), and other critical devices.
    • Data flows: Identify central data flows within the network, highlighting the sources, destinations, and data processing stages.
    • Disaster recovery (DR) outlines: Provide a brief overview of the existing DR strategies.

Document the Network

    • Create or Update Network Diagrams: Include all network segments, connections, and critical devices (routers, switches, firewalls).
    • Identify Critical Assets: Mark systems that store, process, or transmit sensitive information.
    • Network Segmentation: Document how the network is segmented, especially areas with sensitive data.
    • Document Servers and Systems
    • Inventory: List all physical and virtual servers with their roles, operating systems, and critical applications.
    • Configuration Standards: Document the configuration standards for each type of server.
    • Access Controls: List access control measures in place for each server.

Document Data Flows

    • Data Flow Diagrams: Create diagrams showing how data moves through your systems, highlighting where data is stored, processed, and transmitted.
    • Data Classification: Document data classification (e.g., public, confidential, sensitive) and the controls in place to protect it based on its classification.
    • Third-Party Data Sharing: Document any data shared with or received from third parties, including the controls and agreements in place.

Use Visual Aids

    • Create simple diagrams and charts to visualise the network layout, data flows, and server organisation.
    • Visual aids can be crucial for overcoming language barriers and ensuring accurate understanding across teams.

Schedule Regular Updates and Reviews

    • Set up regular meetings or video calls with the core team and other SMEs to review the progress, clarify doubts, and validate information.
    • Use these sessions to address any misunderstandings or language-related issues promptly.

Create a Glossary

    • Develop a glossary of terms and acronyms used in the documentation to ensure everyone understands the terminology clearly.
    • This team members for whom English is a second language.

Document Disaster Recovery

    • Document Disaster Recovery (DR) Plans
    • DR Strategies: Outline strategies for data backup, recovery sites, recovery point objectives (RPOs) and recovery time objectives (RTOs).
    • DR Procedures: Document detailed DR procedures for different scenarios (e.g., data breach, natural disaster).
    • Testing Records: Include records of DR plan testing, issues identified, and corrective actions taken.

Review Policies and Procedures

    • Ensure all IT policies and procedures are up-to-date and compliant with relevant standards and regulations, including access control policies, data protection policies, and incident response plans.

Review and Feedback Cycle

    • Implement a thorough review and feedback cycle involving all SMEs to ensure the accuracy and completeness of the documentation.
    • Be open to feedback and willing to make adjustments based on insights from team members with different perspectives.

Conduct Internal Assessments

    • Perform a self-assessment to identify gaps in documentation, policies, or procedures.
    • Use checklists or auditing tools to simulate the audit process.

Training and Knowledge Transfer

    • Conduct training sessions to review the documents and ensure everyone understands the content.
    • Use these sessions to refine the documentation further based on questions and feedback.

Conclusion

An IT audit for a data centre migration is critical in ensuring that the migration is executed effectively and securely and complies with all relevant requirements. By systematically evaluating each migration phase, organisations can proactively mitigate risks, address potential issues, and ensure a smooth transition to the new environment.

 

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.

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.

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.