Tag: ISO 27001

Don’t Overlook the Technical Author: A Question for Project Managers

Project managers often bring technical authors in too late. Experienced technical authors can reduce delivery risk by shaping documentation early—supporting IT audits, ITIL-aligned processes, ISO 27001/ISO 9001 controls, disaster recovery packs, incident and change management, and operations manuals. Know your technical author before you assume their limits.

Tweet
Pin
Share
0 Shares

Here is a question for project managers:

How many projects did you manage where the team treated the technical author as an afterthought or excluded them entirely?

It happens more often than it should. Project managers view documentation as something to “do at the end”, once the teams finish the proper work and the delivery pressure is at its peak.

That is when teams discover the cost of leaving documentation too late.

By the time the project is in closure mode, you have already missed the point where a technical author adds the most value.

The mistake: assuming the technical author is “just a writer”

Many project managers underestimate what an experienced technical author actually does. They think we:

      • only polish text,
      • rewrite technical material in plain English,
      • only fix formatting.

That is only one part of the job.

Technical authors understand IT operations and governance. They have documented services for years. This experience extends to audits. They know how to gather evidence.

What an experienced technical author may already know

A technical author may already have delivered documentation for:

      • IT audits and compliance preparation
      • Disaster recovery (DR) documentation
      • Operations manuals and runbooks
      • Incident, problem, and change management processes
      • Service transition documentation
      • Knowledge base and repository design
      • Information governance and document control
      • Data centre migration documentation
      • ITIL-aligned documentation structures
      • ISO 27001 and ISO 9001 aligned document frameworks

These are not theoretical skills. They come from being repeatedly embedded in delivery and operational environments across different organisations and clients.

The risk: documentation gaps that become delivery risks

When you exclude technical authors from early planning, projects often run into the same problems:

      • They discovered the documentation gaps late.
      • Missing operational detail that prevents handover
      • Inconsistent terminology and process steps
      • Rework caused by unclear ownership and review routes
      • Poorly structured repositories that no one can navigate
      • Evidence gaps that become audit risks
      • Last-minute “document sprints” that no one has time for

These issues are rarely “writing problems” but planning problems which are avoidable.

Know your technical author before you assume their limits

Every technical author has a unique history. Some come from engineering, some from software and infrastructure, some from compliance-heavy environments, and some from service operations.

You will not know what capabilities you have access to unless you ask.

Here is a simple, early-project habit that saves pain later:

Sit down with the technical author and establish what they’ve done before.

Ask questions like:

      • What types of projects have you supported?
      • What frameworks do you work with (ITIL, ISO 27001, ISO 9001)?
      • What operational documentation have you delivered (DR packs, ops manuals, runbooks)?
      • What documentation risks do you expect on a project like this?
      • What do you need from the team to avoid last-minute document chaos?
      • You may find they know more about documentation governance, operational readiness, and audit evidence than you expected.

Documentation is not an output. It is part of the delivery.

Documentation is not a box to tick at the end.

It is part of how projects:

      • reduce operational risk
      • pass audits
      • transfer knowledge
      • support teams
      • enable safe change
      • transition into BAU without firefighting

A technical author is not “just the person who writes things down”.

A strong technical author is often one of the few people on a project who thinks in terms of:

      • structure
      • lifecycle
      • traceability
      • usability
      • governance
      • evidence

Last point: never overlook the technical author

If you want better delivery outcomes, involve documentation earlier and treat it as a work stream with ownership and design—not a clean-up job.

Never overlook the technical writer.

Because the best technical authors are not just documenting your project.

They can make it work.

Have you ever consulted your technical author on previous deliverables to identify and reduce project risks?

Document Strategy vs Document Plan: Why Most Organisations Get It Wrong

Introduction

In the world of technical authoring and information management, people often use two terms interchangeably, but understanding your document strategy is key to approaching both effectively.

      1. Document strategy
      2. Document plan

They are not the same.

Confusing them is one of the main reasons documentation becomes reactive, inconsistent, and vulnerable to managerial interference.

If management treats documentation as administrative output rather than a governed asset, it will always sit at the whim of whoever speaks loudest.

This article explains:

      1. What a document strategy actually is
      2. What a document plan does
      3. Why governance matters?
      4. What must senior technical authors implement to protect documentation assets?

What is a document strategy?

A document strategy defines how documentation supports organisational objectives. It is not:

      • a list of deliverables.
      • a collection of templates.
      • a SharePoint structure.

It answers fundamental questions:

      • Why does documentation exist in this organisation?
      • What risk does it mitigate?
      • What decisions must it support?
      • What compliance obligations must it satisfy?
      • Who owns it?

In regulated environments, document strategy connects directly to standards such as

      • ISO 9001 (Control of Documented Information)
      • ISO/IEC 27001 (information security controls)
      • ITIL (service documentation and knowledge control)

If documentation is required for audit, certification, or regulatory compliance, you must govern it strategically.

What a proper document strategy includes

A credible document strategy defines:

1. Governance Model

      • Clear document ownership
      • Defined author vs reviewer vs approver roles
      • RACI alignment
      • Escalation routes

2. Lifecycle Control

      • Create → Review → Approve → Publish → Maintain → Retire
      • Mandatory review cycles
      • Version control standards
      • Archiving criteria

3. Classification and Security

      • Controlled vs uncontrolled documents
      • Public vs restricted
      • Security classification tiers

4. Architecture and Structure

      • Taxonomy
      • Metadata standards
      • Naming conventions
      • Document numbering schemas

5. Decision Framework

      • What qualifies as controlled documentation?
      • What does not?
      • When documentation is proportionate
      • When a knowledge article is sufficient

Without these elements, documentation becomes personality-driven rather than policy-driven.

What is a document plan?

A document plan is operational.

It applies the strategy to a specific project, programme or service.

Where strategy defines governance, the plan defines delivery.

It answers:

      • What documents are required?
      • Who is writing them?
      • When are they due?
      • What reviews are mandatory?
      • What approvals are needed?
      • How do they align with stage gates?

In complex programmes — such as digital transformation, DMS rollout, or security accreditation — a document plan ensures traceability and sequencing.

Without a document plan, documentation is:

      • Rushed at the end
      • Inconsistent across work streams
      • Duplicated across teams
      • Politically rewritten

Why Documentation Falls “at the whim of managers”

Documentation becomes unstable when:

      • There is no documentation policy
      • Templates are uncontrolled
      • Metadata is optional
      • No audit mechanism exists
      • No one owns lifecycle enforcement

In that vacuum, managers step in.

They introduce:

      • New templates
      • Personal preferences
      • Structural changes
      • Ad hoc requirements

The result is entropy.

Governance prevents that.

What technical authors must do beyond writing

Senior technical authors must move beyond content production.

They must act as:

      • Information architects
      • Governance stewards
      • Lifecycle controllers
      • Risk mitigators

Below are the controls that protect documentation assets.

1. Establish documentation governance

Create:

      • Documentation Policy
      • Document Control Procedure
      • RACI matrix
      • Change management workflow for templates

Ensure:

      • Template changes require approval
      • New document types require justification
      • eliminate uncontrolled versions

2. Enforce metadata and taxonomy

Metadata is not optional in mature environments.

Define mandatory fields such as:

      • Document Owner
      • Service Area
      • Security Classification
      • Review Date
      • Version Number

Implement enforcement within:

      • SharePoint libraries
      • Asite or DMS platforms
      • Controlled repositories

If you do not enforce metadata, the structure collapses.

3. Institute review discipline

Set:

      • Annual review cycles (minimum)
      • Risk-based review frequency
      • Automated reminders
      • Expiry flags

Outdated documentation creates audit exposure.

4. Run documentation audits

Introduction:

      • Quarterly sampling
      • Annual full audit
      • Traceability verification
      • Redundancy elimination

Without an audit, decay is inevitable.

5. Design templates that enforce structure

Most engineers and technicians do not read style guides.

They follow structure.

Well-designed templates:

      • Force styles
      • Control numbering
      • Embed guidance
      • Reduce formatting drift
      • Prevent structural inconsistency

Templates are governance tools disguised as formatting aids.

6. Define what not to document

Over-documentation creates noise.

A strong document strategy specifies:

      • What must you control?
      • What belongs in a knowledge base?
      • What remains in the service tools?
      • What is transient and disposable?
      • Clarity reduces clutter.

Document strategy maturity model

Organisations typically sit at one of these levels:

Level Description
Level 1 Ad hoc and personality-driven
Level 2 Template-based but uncontrolled
Level 3 Defined lifecycle and metadata
Level 4 Audited and measured
Level 5 Strategically aligned to risk and performance

Most organisations sit between Level 1 and Level 2.

A mature technical author moves them to Level 3 and beyond.

The critical distinction

      • Document Strategy = Governance + Risk Alignment + Structure
      • Document Plan = Delivery + Scheduling + Accountability
      • Ongoing Stewardship = Control + Audit + Discipline

Writing is only part of technical writing.

Control is the real work.

Final Thought

If A.N. Other can alter documentation at will, it is neither governed nor strategic.

And if it is not strategic, the user will not treat it as a corporate asset.

When being Ignored teaches you everything

If your employer ignores you most of the time, then they turn their attention towards you, never in a way that helps. They expect you to mend years of neglect. They want you to perform miracles without context and then ask why you haven’t fixed it already. You explain — again — that you’ve asked for help, for guidance, for support, but were ignored because everyone else was “too busy.” That’s when you realise: they don’t want a technical author; they want a miracle worker. Demanding scenarios test the technical author’s resilience.

I’ve lived through that more times than I care to count. I’ve served under managers who were bullies. They took credit for my work and left me to take the blame when their own ideas fell apart. I’ve been sacked twice because I became the scapegoat for a junior manager eager to broaden his horizons without knowing how to do it the right way. Somehow, I managed to survive, demonstrating technical author resilience under pressure.

After the shock of those experiences, I tried to leave the profession altogether. But escape was impossible. Technical communication isn’t just a job you walk away from — it becomes part of how you think, how you analyse, how you explain. Still, the idea lingered: perhaps I could find a new path, somewhere I didn’t have to fight to be heard.

Being ignored forced me to grow and build my knowledge in

      • document control,
      • SharePoint,
      • metadata,
      • ISO standards, and
      • information management strategy.

Every new skill became a means of self-preservation and a step towards independence. My strength wasn’t just writing documents, but creating clarity in confusion. I turned chaos into structure. This growth marked a new level of resilience for me as a technical author.

Over the years, I’ve met many technical authors who perform communication miracles. Often introverted by nature, they bridge the gaps between.

      • development,
      • product management,
      • marketing, and
      • compliance.

They mediate conflicts, resolve ambiguities, and keep projects moving. They balance diplomacy and precision. Yet despite this, recognition remains elusive. Juggling all those pressures while being expected never to drop a ball is the unique burden of our profession. It truly tests our resilience.

When I look back, I can see how much those early challenges shaped me. The failures, the bullying, the long stretches of being overlooked — they all built resilience and empathy. They taught me how to read a room, how to listen, and how to pick my battles.

In later years, even as contracting became my refuge, the dream of escape began to fade.

Lone desk lamp symbolising resilience and focus in an overlooked workplace
Lone desk lamp symbolises resilience and focus in an overlooked workplace

Where would I go?

Who else would understand this strange blend of discipline, communication, and problem-solving?

This is where the resilience of a technical author comes in.

On more than one occasion, a recruitment agency shared something with me that has stuck in my mind:

“You’d make a great recruiter — you’re easy to talk to, confident, and you make even the most complex role sound exciting.”

Perhaps they were correct. During this time, I truly mastered translation—not just between systems and users, but also between individuals and possibilities.

My article appears after reading Dr Harald Schenda’s linked article. It resonated with me, and here is my response with his acknowledgement.

https://www.linkedin.com/posts/harald-schenda_technicalwriting-technicalcommunication-technischekommunikation-activity-7389332802388848640-01t8?utm_source=share&utm_medium=member_desktop&rcm=ACoAAADzAZwBkR4cshHQHZzdgski5orzlKnCer0

Beyond the Dash Debate: How AI Is Reshaping Writing and Technical Authoring Careers

Beyond the Dash Debate: How AI Is Reshaping Writing and Technical Authoring Careers

Writers and technical authors often debate AI’s punctuation quirks — from dash usage to tone. But while we’re arguing over commas, something larger is happening.
Artificial intelligence is not changing how we write; it’s changing why we write — and what value we bring when machines can generate text faster than we ever could.

The question isn’t whether GPT overuses em dashes.
It’s whether we’re ready to evolve beyond them.

1. From Author to Information Architect

AI can produce paragraphs in seconds, but it can’t design the logic behind them.
Tomorrow’s writers won’t just create content — they’ll become information architects who define structure, intent, and compliance.

In regulated environments such as the defence, nuclear, or financial sectors, AI still needs guidance on how to ensure documents comply with frameworks such as ISO 27001, ISO 9001, or PCI DSS.
Writers who understand these standards — and who can teach AI systems to follow them — will remain essential.

2. From Content Creation to Documentation Governance

The flood of AI-generated content means accuracy, version control, and authorship assurance have become critical.
This is where documentation governance takes centre stage.

Technical authors can pivot from writing to governing:

      1. Reviewing AI output for factual and procedural accuracy.
      2. Enforcing metadata and lifecycle rules within DMS tools like Asite or SharePoint.
      3. Building automated checklists and templates that ensure consistent document quality.

AI can draft — but humans must validate.

3. Human Interpretation Still Matters

AI can mimic tone and style, but it cannot sense how a message lands.
When a document must persuade, reassure, or instruct, context becomes everything.
Writers with empathy, domain understanding, and communication insight remain vital to bridging human and machine.

The technical author’s future lies in translation and interpretation: turning data into understanding, and ensuring meaning survives automation.

4. Ethics, Attribution, and AI Literacy

As organisations adopt AI-assisted documentation, they’ll face new ethical challenges:

      1. Who owns AI-generated content?
      2. How do we ensure traceability of information sources?
      3. How do we prevent bias and misinformation?

Writers and documentation specialists can lead the development of AI content policies, establishing governance frameworks and training programmes that uphold accuracy and transparency.

Becoming an AI-literate communicator is now as valuable as being a clear writer.

5. Adaptation, Not Extinction

AI doesn’t erase writing jobs — it redefines them.
Those who adapt will move from creators to curators, validators, and strategists.

Future-ready writers will:

      1. Design content architectures rather than just fill them.
      2. Develop governance systems that manage AI output.
      3. Train teams in writing assurance and ethical documentation.
      4. Blend communication, compliance, and creativity.

In short, they’ll stop being hands-on writers and start being writing strategists.

Conclusion: Evolving Beyond the Dash

So yes — debate GPT’s dash usage if you like.
But remember: punctuation debates won’t protect your profession.
Evolution will.

Writers who move toward governance, structure, and strategy will not just survive AI — they’ll define how it’s used.
The end of writing isn’t coming.
It’s simply the beginning of a new chapter.

Call to Action

If you’re a technical author or documentation manager looking to future-proof your role, start building skills in information architecture, AI literacy, and documentation governance.
Follow techwriting.co.uk for upcoming guides on adapting your documentation strategy in the AI era.

Why Isn’t Technical Authoring Taken as Seriously as Business Analysis?

Business analysis has established itself as a standard in structured career paths. Business analysts operate within a framework that includes certifications from BCS and IIBA, as well as a global knowledge base represented by the BABOK. They play a vital role in driving business success. However, why hasn’t technical authoring training kept pace with the discipline and received the same level of recognition?

Yes, there are training courses for technical authors—but for those of us with real-world experience, most courses offer little new. They often cover areas we’ve long since mastered: writing, using templates, and understanding basic tools. That leaves a pressing question:

Why hasn’t the technical writing profession grown to support mid- to senior-level authors with meaningful, strategic development?

The Perception Problem: Writers vs. Strategists

Part of the issue lies in perception. People often view technical writing as a “support function”—a downstream activity added after the “real” work is done. In contrast, business analysts work upstream, shaping project and product design.

Because of this, organisations rarely invest in upskilling technical writers beyond entry level. We receive tool-specific training, such as MadCap Flare, FrameMaker, and DITA, as well as refresher courses on grammar and plain English. Training in information strategy, content governance, and integrating documentation with Agile processes is essential, yet it is rare. These skills are vital for technical writers to excel in high-performing digital teams.

Why Experienced Technical Authors Avoid Most Training

As a senior technical author, I know training courses are available on the market, but I’ve yet to find any that add value to what I already know.

Here’s why most courses don’t appeal to experienced writers:

      • Too basic, they cover foundational topics like sentence clarity, structure, and Microsoft Word formatting.
      • Tool-led, not strategy-led: Courses focus on software, not how to use documentation to improve business outcomes.
      • One-size-fits-all: Most assume a junior audience, not someone managing document lifecycles or architecting knowledge bases.

This gap motivated me to independently pursue learning through peer networks, mentoring, and cross-disciplinary knowledge, often without formal recognition or support.

What Training for Technical Authors Should Look Like

If we’re to upskill and advance, we need training that goes beyond surface-level writing mechanics.

High-Value Topics for Mid-to-Senior Technical Authors:

Focus Area Why It Matters
Information Architecture & UX Writing Create usable, intuitive, and findable documentation across systems and platforms.
Agile/DevOps Documentation Integration Align with sprint cycles and release documentation iteratively.
Content Governance & Strategy Build scalable systems for content reuse, version control, and quality assurance.
Metadata and Taxonomy Design Essential for working in SharePoint, Asite, or any modern content repository.
API & Developer Docs More projects now require integration-level documentation and OpenAPI familiarity.
AI-Assisted Authoring learn  how to partner with, not be replaced by, content generation tools.
Accessibility and Inclusive Writing Meet compliance, usability, and ethical standards for broader audiences.

The Bigger Issue: Lack of a Unified Knowledge Base

Business analysts have the BABOK, project managers have PRINCE2 and PMBOK, and technical authors? We have fragmented resources, small communities, and ad hoc training.

There is currently no universally accepted body of knowledge that technical authors follow. No recognised framework exists that organisations can use to:

      • structure roles,
      • develop teams, or
      • plan career paths for technical writers.

Until we establish such a structure, we will continue to be seen as individual contributors rather than strategic enablers.

What Needs to Change

To elevate the profession of technical authoring, we need:

      • Advanced Masterclasses for experienced authors.
      • Courses that blend strategy, tech, and communication, not just software skills.
      • Advocacy from inside the profession—to influence HR, procurement, and leadership views.
      • Recognition of our roles in content strategy, product success, and compliance.

Final Word: It’s Time to Professionalise the Profession

Training for technical authors exists, but unless it reflects the real-world complexity of our roles, it won’t be worth our time or investment.

Technical authors are no longer just documenters—we’re architects of information. Our training, recognition, and role in organisations must reflect that.

Let’s continue the conversation

Have you taken a valuable course? Do you want to help shape better training for technical authors? Let’s talk.

Why Companies Struggle with Infrastructure Documentation—and Why It Matters

Why Infrastructure Documentation Is Your Most Overlooked Security Asset

Many companies struggle to document their IT infrastructure effectively.
As a seasoned technical author, I’ve seen firsthand how well-written Infrastructure documentation transforms chaos into clarity—helping teams work smarter, faster, and more securely.

Documentation: Your Strategic Advantage

Infrastructure documentation isn’t just admin paperwork — it’s a strategic business asset.

When your documentation is accurate, structured, and up to date:

      • Teams resolve incidents faster.
      • New staff onboarded seamlessly.
      • Projects maintain continuity and compliance.
      • Prevent costly errors before they occur.

In short, infrastructure documentation drives operational excellence — saving time, reducing risk, and strengthening your organisation’s resilience.

The Rising Challenge of Security & Compliance

In today’s digital landscape, businesses face intense security and compliance pressures. Frameworks such as ISO 27001, NIST, and GDPR set clear expectations for protecting sensitive data and improving cyber resilience.

But here’s the problem:
These frameworks don’t tell you how to write, update, or manage the documentation that underpins compliance.

That’s where organisations often fail. Outdated documents, missing ownership, and inconsistent version control can derail even the best security strategies.

To succeed, you must treat documentation as a living, evolving resource — not a one-time deliverable.

Building a Well-Managed Documentation Repository

Drawing on NIST, ISO 27001, and GDPR guidelines, I’ve helped organisations create robust documentation frameworks that withstand audit and operational scrutiny.

Hiring a skilled technical writer is a small investment compared to the cost of failure. Consider this:

IBM’s Cost of a Data Breach Report (2023) put the average cost of a data breach at £3.8 million.

Would you rather invest a fraction of that in proactive documentation—or risk the aftermath of a ransomware attack or compliance breach?

Documentation That Drives Operational Excellence

High-quality documentation isn’t just about compliance. It’s the foundation of operational efficiency.

Imagine a single source of truth that everyone can access—accurate, consistent, and regularly updated. The results:

      • Faster issue resolution.
      • Reduced reliance on informal knowledge.
      • Lower risk from staff turnover.
      • No time wasted reinventing processes.

Good documentation = Sustainable operations.

Here’s what effective documentation management looks like:

      • Defined policies and processes.
      • Accessible, searchable repositories.
      • Regular reviews and updates.
      • Quality checks for clarity and consistency.

The Bottom Line

Poor documentation isn’t just inconvenient — it’s a serious business risk.
The cost of bad writing far outweighs the price of hiring a professional technical author.

Don’t let your organisation fall behind.
Invest in structured, secure, and well-maintained documentation — and protect your business for tomorrow.