Tag: technical authoring

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 Is a Document Strategy Not a Strategy?

A practical guide for organisations that want governance to work

Tweet
Pin
Share
0 Shares

A practical guide for organisations that want governance to work

In many organisations, a document strategy looks impressive.

      • It has executive sponsorship.
      • It references digital transformation.
      • It talks about lifecycle, governance, compliance, and knowledge reuse.

And yet — nothing changes.

      • Documents are still duplicated.
      • Templates are ignored.
      • Review cycles drift.
      • Audit findings repeat.

At that point, the issue is not the document strategy itself. The issue is how the organisation treats the strategy document as the outcome, rather than as a mechanism for decision-making.

This article examines when a document strategy stops being strategic — and how to recognise the difference between a living governance framework and a glossy artefact.

What is a document strategy?

A document strategy should define:

      • How information is created

      • How it is controlled

      • How it is reviewed

      • How it is distributed

      • How it is kept or archived

      • Who is accountable at each stage?

In regulated environments — particularly those aligned with ISO 27001, ISO 9001, PCI-DSS, nuclear, defence, or financial services — this is not optional. Documentation underpins audit defensibility and operational resilience.

However, a document strategy becomes ineffective when it fails to influence real-world behaviour.

1. If it avoids constraints, it is not a strategy

A genuine strategy makes trade-offs.

It defines constraints such as:

        • Budget limits

        • Tooling capability

        • Cultural maturity

        • Political appetite for enforcement

        • Regulatory exposure

If a document strategy attempts to optimise for:

        • Speed

        • Full compliance

        • Zero friction

        • Maximum flexibility

        • Minimal cost

Simultaneously, it is not strategic. It is aspirational.

For example:

      • You cannot have complete audit traceability without adding some process overhead.

      • You cannot maintain full template discipline while allowing unlimited author freedom.

      • You cannot achieve a single source of truth without closing down local storage practices.

Strategy requires subtraction. If nothing is excluded, nothing is prioritised.

2. If it does not change governance, it is Theatre

A document strategy must show up in operational systems.

You should see its fingerprints in:

      • Metadata schemas

      • Document numbering conventions

      • Version control rules

      • Approval workflows

      • Access permissions

      • Review cycles and SLAs

      • Archival and retention schedules

If your strategy claims to be a “single source of truth” but documents continue to sit on local drives, shared mailboxes, and uncontrolled Teams folders, then the strategy has not reshaped behaviour.

If it promises improved knowledge reuse but there is no taxonomy, no tagging discipline, and no ownership of content review, it remains rhetoric.

A useful test is this:

      • Did the strategy alter the document lifecycle?

      • Did it remove duplicate repositories?

      • Did it redefine what “approved” means?

      • Did it assign clear accountability?

If not, it is governance theatre.

3. If it cannot be operationalised, it is Philosophy

Strategic language often becomes abstract.

      • “Drive digital transformation.”

      • “Enhance collaboration.”

      • “Embed knowledge excellence.”

These statements are ambitions, not mechanisms.

Operational strategy answers concrete questions:

      • Who owns lifecycle integrity?

      • What is the RACI model?

      • What happens when review deadlines are missed?

      • What constitutes a controlled document?

      • What is the escalation path for non-compliance?

      • What is the maximum tolerated duplication level?

If delivery managers and technical authors cannot convert the strategy into day-to-day rules, then it is conceptual rather than actionable.

In high-compliance sectors, this gap becomes visible during audits. Auditors increasingly test evidence of implementation, not the existence of documentation.

4. If it does not influence decisions, it is Decorative

A real document strategy shapes:

      • Recruitment decisions

      • Tool selection

      • Investment priorities

      • Change control

      • Incident response

      • Audit preparation

If no board paper references it, if no funding decision cites it, and if no hiring decision reflects it, then it is decorative.

A strategy that is only opened during audit season is not embedded.

5. If it is written only for executives, it will fail

Authors write strategies in executive language:

“We will implement a structured document lifecycle aligned to industry best practices.”

Delivery teams interpret this as:

“Another template change.”

If engineers, technicians, and operational staff cannot explain what the strategy means for their daily work, the communication has failed.

Clarity is structural. Not cosmetic.

In environments where engineers write occasionally rather than professionally, a well-designed template with enforced styles often achieves more than a 30-page style guide.

If the strategy does not account for real author behaviour, it will be bypassed.

6. If it ignores culture, it is naive.

People do not resist governance for ideological reasons. They resist friction.

If your document strategy increases:

      • Form complexity

      • Metadata burden

      • Approval latency

      • Review bottlenecks

Without demonstrating value, users will route around it.

A realistic strategy accounts for:

      • Author maturity

      • Training capability

      • Tool usability

      • Political support for enforcement

It does not assume ideal behaviour.

The Digital Strategy Problem

Digital strategies often attempt to solve everything at once:

      • Content management

      • Knowledge management

      • Collaboration

      • Automation

      • AI

      • Governance

      • Records management

      • Compliance

      • Cultural change

This breadth dilutes focus.

A disciplined document strategy might say:

For the next 24 months, our priority is lifecycle control and audit defensibility. Automation and AI integration are out of scope.

That level of constraint is strategic clarity.

A Practical Test for Organisations

To assess whether your document strategy is real, ask three questions:

      1. What decision did we make differently because of this strategy?

      2. What did we deliberately choose not to do?

      3. Who would notice if we ignored it?

If no one would notice, it is not a strategy.

What a real document strategy looks like

A credible document strategy:

      • Defines constraints

      • Forces trade-offs

      • Embeds into tooling configuration

      • Alters decision rights

      • Clarifies accountability

      • Survives audit scrutiny

      • Is understood at operational level

      • Drives measurable change

In regulated and compliance-heavy environments, strategy is not narrative. It is architecture.

If it does not reshape structure, authority, and process, it is branding. Branding is not a strategy.

Is Your Job Title Holding You Back as a Technical Author?

Technical authors often sit at the centre of multiple content and information disciplines. This visual shows how closely our work aligns with roles such as Content Designer, UX Writer, Information Manager, and Documentation Strategist. Many of these job titles describe work that experienced technical authors already perform daily—metadata design, information architecture, content strategy, documentation governance, and user-focused writing.
The overlap raises an important question for our profession: is the title “Technical Author” reflecting the full scope of what we do, or is it quietly holding us back?

Tweet
Pin
Share
0 Shares

Is the Technical Author Job Title Limiting Your Career?

tecnical cross over

Here’s a hard truth. Most experienced technical authors acknowledge that there is only so far you can go while keeping the technical author job title.

I contracted for a variety of reasons: exposure and opportunities that permanent roles rarely offer. But after 18 years, another realisation emerges:

The job title itself can become a barrier.

The work is not limited; rather, the perception of our title is.

When Your Title No Longer Matches Your Skills

After years in the field, you notice something interesting:

People with far more impressive job titles are performing tasks you’ve been doing for years:

      • Information Managers
      • Content Designers / Content Strategists
      • Documentation Project Manager
      • Knowledge Managers
      • UX Writers
      • Content Operations Leads
      • Information Architects

And you wonder:

What are they doing that I haven’t done?
What specialism do they possess that a seasoned technical author doesn’t?

More often than not, the answer is:
very little. Sometimes, nothing at all.

Technical authors often perform similar tasks, using diverse labels.

The Hidden Skill Set of an Experienced Technical Author

Most technical authors—especially those with 10, 15, or 20+ years’ experience—already operate far beyond “writing user guides.”

They work across.

      • Information Structure & Strategy
      • Information architecture
      • Metadata and taxonomy design
      • Naming conventions and file governance
      • Knowledge base design
      • Documentation life cycle models
      • SharePoint, Confluence, and DMS structuring

Process Writing & Compliance

      • ISO 27001 documentation
      • ITIL-aligned processes (incident, change, problem)
      • GDPR, PCI/DSS, risk and policy frameworks
      • Governance workflows

Digital Content & UX

      • Content design
      • User journey mapping
      • Plain English and accessibility
      • User research and SME interviews

Project & Stakeholder Management

      • Documentation strategy
      • Template development and automation
      • Editorial oversight
      • Managing SMEs, engineers, and senior stakeholders

These are not junior writing tasks—this is information management and content strategy in practice.

Yet the title “Technical Author” hides this complexity.

Why Other Job Titles Are Perceived Differently

The difference is rarely in capability.
It’s framing, branding, and expectation.

      • A Content Designer suggests UX alignment.
      • A Knowledge Manager suggests ownership of information ecosystems.
      • A Documentation Manager suggests governance, leadership, and structure.
      • An Information Architect suggests digital systems thinking.
      • A Documentation Strategist suggests planning, analysis, and long-term direction.

The work may be the same, but the title expands your perceived value.

Meanwhile, “Technical Author” still signals one thing to many people:

“The person who formats documents and writes instructions.”

Nothing could be further from the truth—but titles shape perception.

When Your Title Becomes a Career Constraint

After a long time in the role, many technical authors reach a point where:

      • They manage information, not just documents.
      • They build documentation ecosystems, not just templates.
      • They lead strategy, not just writing.
      • They’re treated as senior contributors, but their titles don’t reflect that.

This mismatch can stop progression into:

      • leadership roles
      • consulting opportunities
      • digital content positions
      • information governance roles
      • strategic documentation work
      • higher-pay permanent posts
      • In many organisations, everything hinges on the title.

So should you change your job title?

Yes — but do it strategically.

Choose a title that reflects the true scope of your knowledge:

      • Documentation Strategist
      • Information Manager
      • Knowledge Manager
      • Content Architect
      • Technical Content Lead
      • Documentation Programme Manager
      • Content Operations Lead
      • Information Architect

These titles communicate your role extends beyond writing into:

      • structure
      • governance
      • strategy
      • lifecycle management
      • digital ecosystems
      • content design
      • compliance
      • tooling
      • information flow
      • Exactly the things you already do.

A Final Question for Fellow Technical Authors

Before you update your CV, LinkedIn, or next job application, ask yourself:

      • Is your current job title helping you progress — or holding you back?
      • And if it’s the latter, what title reflects the work you already do?

Why You Should Listen to Your Technical Author — Even When You Think You Know Better

Ever get the sense that when you speak as a technical author, people politely nod but don’t actually hear what you’re saying? If so, some wise documentation advice could enhance both the clarity and impact of your communication.

It’s not imagination. Proper guidance on documentation advice can counter this tendency.

This is a subtle bias, such as believing Bob is correct because of familiarity, even if he lacks tech doc knowledge.

In most organisations, people listen to familiar voices. They trust people they know well. However, when a technical writer gets involved, things change due to the rules, organisation, and clear communication they bring. Suddenly, everyone becomes an expert in “how to write.” This is where following the documentation advice becomes crucial.

The comfort of familiarity

Humans trust familiar things naturally. If a colleague has been around long enough, their opinions feel like facts. When a technical author points out that a process flow doesn’t align with the policy, or that a new template lacks metadata, the instinctive reaction is often:

“We’ve always done it this way.”

That’s the corporate equivalent of saying, “Don’t confuse me with logic.” Yet, sound advice regarding documentation can mitigate this.

But the technical author isn’t there to disrupt for the sake of it. They are there to create order, consistency, and the ability to track things, which helps avoid problems such as failed audits, redoing work, and project mix-ups.

The illusion of expertise

Documentation seems simple until it’s wrong. Then everyone notices.
Yet when a technical author raises a flag — about inconsistent titles, uncontrolled templates, or missing versioning — it’s often brushed aside. Why? Because others rely on their own facts, shaped by limited experience rather than informed standards.

A common refrain goes something like:

“I’ve written plenty of reports. How hard can it be?”

The problem is, it isn’t about writing. It’s about information architecture, compliance, usability, and lifecycle management. A technical author doesn’t just type; they engineer clarity according to effective documentation advice.

Bias in action

Here’s a real-world pattern you might recognise:

      1. You warn that storing final documents in personal drives will cause chaos later.
      2. It’s ignored.
      3. Months later, someone panics because no one can find the latest approved version.
      4. Suddenly, you’re called in to “fix” it — usually under time pressure.

When people rely on bias and familiarity rather than expertise, the organisation ends up paying twice:

      • once for ignoring the advice, and
      • for cleaning up the mess.

Why listening matters?

Listening to your technical author isn’t about deference — it’s about recognising value.
Your TA sits at the intersection of compliance, clarity, and communication. They understand how documents are consumed, how information flows, and how version control saves reputations. They spot inconsistencies before auditors do by relying on documentation advice.

In short, sound advice for documentation protects you from the chaos that happens when assumptions override process.

Closing thought

So next time your technical author speaks up, pause before deflecting with “We’ll handle it our way.”
The suggestion you’re brushing off could be the difference between passing an audit and receiving a formal corrective action.

In a world full of noise and opinions, the technical author’s voice is one of the few based on structure, clarity, and evidence. It’s not bias. It’s informed by sound documentation advice and expertise.

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.

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.

 

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.

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.

The Hidden Cost of Poor Project Management on Technical Documentation

Poor project management can derail even the best documentation. Learn how planning, collaboration, and respect for technical authors’ timelines help deliver successful projects and user-ready content.

Tweet
Pin
Share
0 Shares

If you don’t plan properly, you’ll drown in documentation while everyone else enjoys a beer.
That’s the reality when poor project management collides with technical documentation.

When planning is weak or missing, documentation quickly becomes chaotic. This article explores how effective project management safeguards documentation quality and keeps technical authors productive — not firefighting.

Put a Plan Around a Project — or a Project Around a Plan

Without a structured project plan, technical documentation is at high risk of failure.
Good project management defines objectives, sets expectations, and prevents unqualified team members from altering scope or priorities.

Documentation cannot replace a plan — but it can rescue a project in trouble. Analysing existing documentation early can highlight risks, reduce rework, and improve overall quality.

Frustration Builds When Planning Fails

Experienced technical authors become frustrated when timelines are unrealistic or when writing is treated as a “quick task.” Common problems include:

      • Non-writers assuming documentation is easy to produce.
      • Unrealistic deadlines that sacrifice quality and accuracy.
      • A lack of understanding of research, review, and editing cycles.

Key takeaway:

Rely on your technical author’s expertise to plan, schedule, and prioritise documentation deliverables.

If deadlines are genuinely tight, create a documentation priority list to ensure users can adopt the product effectively before expanding the scope.

Building Realistic Timelines for Technical Documentation

Every documentation project should include the following core stages:

      1. Research: Understand the technology, product, and user needs.
      2. Writing: Produce structured, clear, and user-focused content.
      3. Editing: Copyedit for consistency, readability, and accuracy.
      4. Review: Validate technical accuracy with subject matter experts (SMEs).
      5. Approval: Integrate revisions and finalise the deliverables.

Skipping these steps leads to poor quality and rework that costs time and money later.

(Internal link suggestion: Link to your blog post on “The Document Lifecycle and Knowledge Management” for context.)

Allow Sufficient Ramp-Up Time

Technical authors need ramp-up time to familiarise themselves with the system or product. Proper project management helps by ensuring:

      • Hardware and software access are granted early.
      • Usernames, passwords, and permissions are available on day one.
      • Time is allocated for learning product behaviour and dependencies.

Ramp-up time is not downtime — it’s a crucial investment in documentation accuracy and long-term efficiency.

(Internal link suggestion: Link to “Maximising Technical Authors’ Skills in the Workplace” for additional insight.)

Review the Reviewers

An organised review cycle ensures documentation is technically sound and consistent. Include these checkpoints in your schedule:

      • Review sessions: Technical staff and project managers validate draft content.
      • Revision cycles: Writers implement feedback before sign-off.
      • Final review: Confirm version control and publish-ready content.

This structured review approach prevents errors, missed updates, and last-minute crises.

Can Project Managers and Technical Writers Get Along?

Absolutely — when both sides understand each other’s contribution.
Project managers bring scheduling and coordination; technical authors bring clarity, structure, and content strategy.

When collaboration works, it results in high-quality documentation that empowers customers to resolve issues independently — reducing support calls, improving user satisfaction, and strengthening organisational trust.

(Internal link suggestion: Link to your upcoming article “Using Technical Authors as Strategic Planners.”)

Final Thought

Poor project management doesn’t just delay documentation — it damages credibility and product success.
When technical authors are integrated into project planning and treated as strategic partners, documentation becomes a competitive advantage instead of a last-minute burden.