Month: January 2018

Technical Writing | General Data Protection Regulations

GDPR

On the 25th May 2018, the new General Data Protection Regulations (GDPR) came into force.

Companies outside the EU

If your Company actively trades within the EU and stores, processes or shares EU citizens’ data, then GDPR does apply to you.

Compliance and documentation

One of the primary rules is that under GDPR Process activities MUST be documented.

Companies are required to maintain a set of Policy, Process and Plan (PPP) documentation to ensure you have evidence to support your claims should the ICO investigate any complaint or breach of data.

Note that the Information Commissioners Office (ICO) could demand to see the written documents

What do you need to consider?

As a technical writer, with experience writing compliance documentation, what can I tell you?

If you are still struggling to start

My Blogs are clear, writing one document, when there is a substantial list to be completed from scratch to sign off is a lengthy process. Even if your department has documents that can be reused, it will still take a long time. Compliance projects are manually intensive and documenting GDPR will need dedicated resources.

My experience could be necessary to help you write and manage those documents. The sooner you contact me, the sooner we can start the road to compliance.

  • Create a standard template with – Statement, In Scope, Version Control, Change History, Distribution Lists, Roles and Responsibilities
  • All PPPs must adhere to GDPR – include in the document ‘The purpose of the document’, ‘The Scope’ and add a list of the GDPR compliances relevant to the PPP you are writing and explain the WHY the company are complying along with the HOW the company will comply.
  • The documentation must be relevant to your business. Generic documentation outlining a PPP will NOT suffice
  • Complete the documentation – do not start and leave a document incomplete then sign off; an incomplete document could fail a Compliance Audit
  • Maintain the detail – do not half explain a process or policy
  • Structure the documentation to avoid duplicating information over several documents
  • That the documentation may need to be ISO 27001 compliant
Does Your GDPR Project need documentationClick To Tweet

 

Project Managers and Technical Writers

Project managers and technical writers are two distinct roles. One of my many skills as a technical writer is organisation. We juggle many tasks and switch between them with ease. People skills are essential when speaking with coders, engineers, and technicians of various shades. In the meantime, we manage a ream of documentation while taking instructions from SMEs. Occasionally, we meet a project manager who has had minimal exposure to technical documentation during a project.

techwriting
Project Managers and Technical Writers

If you’ve never planned the tech writing part of a project, ask your technical writer for help. When project managers and technical writers work together, it helps the project succeed (because it’s well documented) and improves support for everyone.

If you are one of the many project managers who have never worked with technical writers, remember that we are professionals. We will not tolerate technical documentation that fails to meet the needs of others.

Techwriting
Project Managers and Technical writers

So, if you have no direct experience with documentation or technical writers, consider:

      • Please talk with your TW(s) because their experience will provide you with a much-needed background in document management.
      • To help plan the documentation, avoid creating timelines as you progress the project.
      • TAs cannot pull documentation from a hat or generate a document from code.
      • Please speak to the TW(s) to gauge how long it will take to review/write/edit a document. In my experience, many project managers overestimate timelines or, worse, underestimate deadlines. Always build in flexibility to allow for problems in the documentation process.
      • Reviewing a document intended for transformation that exceeds 20 pages will take time (the general rule of thumb is 1 hour per page).
      • The time required for writing
      • Peer reviews
      • Time to have the content technically reviewed

Technical Writing | Passive vs Active Sentences

What is a passive sentence?

A Passive sentence is a grammatical voice prevalent in many of the world’s languages. In a clause with a passive voice, the grammatical subject expresses the theme or patient of the main verb – that is, the person or thing that undergoes the action or has its state changed.

http://en.wikipedia.org/wiki/Passive_sentence

Passive vs Active

I can already hear readers asking, what is a Passive Sentence?

Here goes!

Compare these sentences.

  1. The Application is used to collect data (passive)
  2. Use the application to collect data (active)

or

  1. The key was used to open the door (passive)
  2. Use the key to open the door (active)

or

  1. The wire is fed through the box by the electrician (Passive)
  2. The electrician feeds the wire through the box (active)

Using the active voice, sentences provide a clearer more effective message in technical writing and business writing. The active voice identifies the action and determines who performs that work. For clear examples of passive voice look at government documents, which gives the wording a dull, bureaucratic tone.

Over time, writing in the passive voice becomes a habit, one we should all work to change. Of one thing I can be certain, despite the debates, I will continue to use the active sentence.

Technical Writing | Technical documentation vs Helpdesk

Technical Writing | Interviewing SMEs

One of the many skills a technical writer needs is the ability to form relationships with SMEs. An experienced writer talks to subject matter experts to gather insights for a document. Without their input, the writer will face difficulties producing documents. On one project, I worked with two technical writers. They had their styles of approach, and I have mine.

One of our team members, x,x, had a style and approach that rubbed many SMEs the wrong way. I have a laid-back approach. If the SME could not talk because of urgent work, then that’s fine—we can reschedule the conversation. X.X found it difficult to communicate with technical SMEs, which made it challenging to gather the information. He had never worked in the technical field coming not from a technical background, but a process background where people are polite.

Approaching and Interviewing  SMEs 

  1. Ensure you schedule a meeting with the SME in advance. Please do not turn up at their desk and expect to talk.
  2. If you collaborate with other technical writers, review the project plans and inquire whether they have contacted the subject matter expert (SME) regarding topic XYZ. If they have, verify the information is what you need. In such cases, refrain from requesting the SME to reiterate the information.
  3. I use a dictaphone to record interviews because I can always run the recording back if I have any queries. To date, no SME has objected to me recording the conversation.
    approaching and interviewing subject matter experts
    approaching and interviewing subject matter experts
    • If they DO, it will mean listening intently and writing the information
  4. Approach the Interview at the appointed time:
    • Do not be surprised if the SME cancels the meeting because of other demands,
    • If so, reschedule the meeting
  5. Always regard the interview as another knowledge-capture exercise that adds to your experience. Do not assume you know everything before you get there, even if you do.
  6. The SME will assume you understand their language; if not, stop the interview and request a less technical explanation or reassess your ability to do the job if you still do not understand.
  7. Schedule only an hour for the interview, but be clear that you will need to reschedule more time if specific points are unclear.
  8. Be transparent – there will be a peer review required, but you will let them know in advance when the document is ready for review
  9. approaching and interviewing subject matter experts
    approaching and interviewing subject matter experts

    If the SME is not aware of your role or why you need their comments to introduce the project, and if you have not already done so, introduce yourself

  10. The SME may not know everything and will refer you to another SME for information
  11. When you return to your desk, start writing the document. Do not wait for a few days, even if you have recorded the interview.
  12. Carry a pad and pen. You may need to ask the SME to draw the infrastructure.

Technical Writing | Professional vs Amateur, its a matter of choice

A LinkedIn connection shared a poster, which read: Professional vs Amateur; If you think it’s expensive to hire a professional, wait until you hire an amateur.

In 2004 I had an interview in Watford and later Cambridge with software companies looking for a Technical Writer. During the second interview, I had this feeling of deja-vu in that it followed a similar line to the Watford interview. The hiring managers seemed uncertain. The feedback was both companies appointed an internal resource to save money.

Later that year the Watford company after a management buy-out sacked the TA because the documentation failed to meet standards. I was later contacted by an agent after the Cambridge internal appointment failed to deliver.

A previous client called as one of their technical writers had left with work to complete. Once I analysed the work, I made it clear that I had no time to rewrite the work. The manager to keep costs down employed ‘technical writers’ with negligible experience on a high-profile project for a major Telco client.

I can appreciate the fact when times are tough companies like to make a few savings. However, the difference between employing a professional vs. amateur can be stark regarding cost.

Professional vs Amateur, it’s a matter of choice

What you need to consider is the result. Do you want a professional job or a makeshift effort by an amateur? Many experienced technical writers will point out that you get what you pay for. My advice is to be ready to pay the going rate to attract an experienced technical writer who is more than capable of doing the job. In terms of time and delivery, it will save you a lot of time and energy and negate the need to pay twice for the same job.

Technical Writing | Sourcing a technical writer

When sourcing a technical writer, ensure their experience matches your requirements. The best candidate will have the correct background and expertise. Listen carefully to their answers as many like me at the interview dispense advice and why a particular route may not work. If they don’t talk through that experience, keep searching until you do.

Productive years as a Technical Writer

An experienced Technical writer can only be an asset to your team or project. The longer their career in various businesses, the broader and more in-depth their experience will be. However, the only way to be confident is to read their CVs carefully.

Read the CV, and discuss the project. My rule is this: if you cannot see it on my CV, then I haven’t done it. That does not mean I will turn down unfamiliar tasks.

Do they use Social Media or have a website?

Check out LinkedIn for their profile; If you cannot find it or a website describing their experiences, what have they be doing?

During the interview, did they communicate?

During an interview, be wary of a candidate who sits, listens, and says very little. An experienced TW will respond to your questions and offer suggestions on elevating the project with innovations you may not have considered.

Effective communication

An essential part of our job is communicating with SMEs to gather the right level of detail for the documentation. If you have a TW and the documentation appears vague, it might be time for a chat.

Do you want a contractor or permanent TW?

Do you want to build a team that includes a TW to keep the documentation up to date, a person who will grow into the environment? However, I caution against hiring a permanent Technical Writer unless you are sure there will be ongoing work.

Work cycles can dip, so be careful how you use the Technical Writer. During one of my earliest contracts, the project engineer referred to me as a secretary and treated me as one, as did the rest of the team. In a much earlier role, my line manager used me as a general dogsbody.

A proactive Technical Writer between writing, researching and interviewing could improve the company’s documentation. However, once they get on top of the tasks, the role could become routine and repetitive. There will be an odd spurt of activity within the working life cycle; hence, the position of Technical Writing lends itself more to contract work than permanent work.

To summarise: if you hire a permanent Technical Writer to ensure you have plenty of contingencies to avoid your TW developing itchy feet, I suggest you discuss additional tasks that may add value to their experience. Allowing a member of staff use them for jobs for which you employ an office junior will not go down too well.

A word of caution

Unfortunately, our profession attracts its fair share of triers. You can reasonably expect CVs from candidates who have had minimum experience preparing ad hoc documentation on projects at work. Unfortunately, that minimal experience does not translate to full-scale projects requiring a technical writer. In many cases, it turns into an expensive flop.

Many recruiting agents have a minimum expertise sourcing Technical Writers. When they speak to prospective candidates, they hear a few buzzwords and place candidates forward for a role for which they are not suitable. Be sure to check that they have the right experience and background.

To avoid problems, apply the following advice:

Be careful hiring a Junior Technical Writer or one that has worked in a permanent position for the last five years.

Why: a permanent position can be very repetitive, which limits the Technical Writer’s experience. That also goes for junior writers. For high-profile projects, hire a seasoned contracting professional who can talk through the project with you.

Finally, budgets – ensure you are buying the experience you need. In the world of Technical Writing, the price you pay determines the standard you accept. Hiring the wrong candidate could be a costly mistake.

Where else can you source a Technical writer?

You have found me. However, I may not be suitable for the role. Check LinkedIn, Social Media sites and online Job Boards. Ask other companies and fellow professionals if they have used Technical Writers and, if so, what was their experience. They may have recommendations that, in the long run, could save you money.

Technical Writing | The Risks of Poor Document Management in Today’s Workplace

Poor document management is one of the hidden risks slowing down modern businesses. Lost files, outdated versions, and messy shared drives don’t just waste time—they undermine compliance, increase costs, and frustrate employees.

If you’ve ever panicked while searching for the “latest version” of a critical policy document before a big meeting, you’ve experienced the problem firsthand. Without a structured approach to the document lifecycle, companies quickly slide into chaos. The good news? With the right strategy—and the expertise of a skilled technical author—you can transform your documents into reliable, business-critical assets.

A Familiar Scenario

You’re sitting at your desk when your manager asks:

“Can you send me the latest version of our critical policy document? I need it now for a meeting.”

You search SharePoint. It’s not in the correct folder. A keyword search returns hundreds of results. You open several files only to find outdated versions. Panic sets in—your manager is calling again, already late for her meeting.

Most professionals have lived with this frustration. Documents still get lost. Outdated versions pile up, employees create their own file-naming systems, and critical knowledge gets buried. The truth is: traditional file storage is failing your business.

Why Poor Document Management is Costly

Failure to treat business documents as vital assets can lead to:

      • Diminished document utility – staff waste time searching or working with outdated files.
      • Decreased business efficiency – collaboration slows down when knowledge is hard to find.
      • Increased operational risk and cost – mistakes happen, compliance slips, and reputational damage follow.

These risks grow as document libraries expand without control.

Document Lifecycle Management: The Modern Approach

Effective document lifecycle management (DLM) ensures that every business document is valid, compliant, and accessible throughout its lifespan. This approach aligns with industry standards such as ISO 9001, ISO 27001, and ITIL frameworks, which increasingly demand traceability, version control, and accountability.

A modern document management process should cover:

      • Quick access – a centralised repository with search, tagging, and metadata.
      • Frequent review and updating – scheduled reviews to keep documents accurate.
      • Distribution – controlled sharing with the right stakeholders.
      • Conversion – ensuring compatibility across formats.
      • Archiving – moving obsolete versions into a secure archive.
      • Governance – applying version history, approvals, and sign-off processes.

The Role of Technical Authors in Document Management

In today’s workplace, technical authors are more than writers. They are custodians of clarity, consistency, and compliance. A good technical author:

      • Design document templates that meet ISO and ITIL requirements.
      • Establishes metadata fields for versioning, approvals, and document history.
      • Creates plain-English policies and procedures that employees actually use.
      • Trains staff on how to manage documents when no dedicated document controller is available.

By treating documentation as business-critical knowledge assets, technical authors help organisations stay compliant, agile, and productive.

Moving Forward

If your organisation’s document library is growing without control, now is the time to act. Consider investing in a Document Management System (DMS) such as Asite, SharePoint, or Confluence. Pair it with transparent governance and skilled technical authorship, and your documents will support—not hinder—your business.

Key Takeaway

Poor document management isn’t just an inconvenience—it’s a risk to business performance and compliance. By adopting structured document lifecycle management and empowering technical authors, organisations can ensure their knowledge assets remain accurate, accessible, and valuable.

Contact us to learn how we can transform your document management.

Technical Writing | Disaster Recovery Plan

Document the Disaster Recovery Plan

Remember, to be effective you must be prepared to document the plan. Without the documentation you risk the possibility of NOT recovering from a disaster, therefore placing the entire company at risk.

If you have no existing documentation that describes the functions of the company’s servers and their hosted Applications, consider writing relevant Operating Document. In the event of a disaster, without knowing the role and the purpose of a server, as well as the Operating system – it could delay recovery.

A list of your critical systems

All companies will have a set of applications hosted on servers, which, are crucial to the business such as financials.

List your servers by priority and the criticality of the hosted Application – that is the amount of time the server and its applications can remain non-functional before it severely disrupts operations.

Create a disaster recovery plan for each critical system

This returns to the Operating document. To recover the system during a Disaster could take time, more so if the Owner is not available during the disaster to help login and failover the system then failback the system.

Therefore Keep documents simple, direct and to the point and written in such a way that anyone can understand the process, not just the SMEs who designed and built the system.

Who is responsible
Delegated participants must know and understand their responsibility should a disaster happen. Engage them in areas where they will know what to do and act accordingly. When compiling such lists make sure there are Team Leads, and Deputies should the first choice not be available during a disaster.

Make Backups
In this context be sure that if you use allocated drive space that your staff are backing up valuable information and documents to that allocated space.

Do you have an Off-site backup
Store all data in an Off-site Common.

Store Backups off-site in a location away from the same grid as the originals.

Test the Plan
On completion of the written plan, you enter the test phase. Make a plan to failover your infrastructure and then failback the infrastructure.

Take notes along the way to strengthen the areas in the plan which need more validation. Note where there is a need to access backup data time how quickly it takes to restore the system.

Keep the plan safe
Store a paper copy of the plan in a safe place. Remember: during a Failover, the online version could be unavailable.

When it comes to planning your Disaster Recovery strategy, do not forget the disaster recovery documentation. It may be the last project on your mind but could prove to be your company’s one lifesaver.

Disaster Recovery never stops and undergoes modifications every six months or twelve months.

Technical Writing | Technical documentation vs Helpdesk

technical documentation vs helpdesk
technical documentation vs helpdesk

Technical Documentation vs. Helpdesk—Despite the reluctance to invest in technical documentation, many managers need to pay more attention to a proven way to reduce calls to the Helpdesk.

It is common for helpdesks to provide excellent service and manage users’ demands. Technical documentation, such as user guides, often needs to be corrected. Documentation needs to flow and provide practical tips on how to get the most from the software. If your customers had well-written and comprehensive documentation, you could cut back on costly calls to your helpdesk.

Technical documentation vs Helpdesk

technical documentation vs helpdesk
technical documentation vs helpdesk

I have experience in customer service, handling angry customers complaining about the company and its software. They made comments like:

      • The product is bordering on rubbish, and it doesn’t work, is it bugged?
      • annoyed with the company because the software is garbage
      • I can’t follow the user guide because it doesn’t belong to my version of the software
      • I can’t follow the instructions

When documentation cannot deliver the answer, the Helpdesk records a steep curve in calls. Customers who feel forced to call the Helpdesk Support can hold mixed feelings about the product and company.

Frequently Asked Questions (FAQs)

technical documentation vs helpdesk
technical documentation vs helpdesk

Customers are the lifeblood of any organisation, and their demands can vary. I added a feedback option to help users highlight the vague sections of the documentation.

The developers and helpdesk provided a more detailed solution based on their knowledge and experiences. I created an FAQs knowledge base (or Wiki) for external users and placed the information in the back of the document. The internal staff received the content via a RoboHelp *.chm file.

The FAQs were a success and helped cut calls to support by 80%. I had created searchable information that was easy to find and accessible to all staff.

Experienced technical writers can produce audience focussed documentation that helps customers maintain productivity.

Technical documentation vs Helpdesk

Treat your documentation and information as valuable assets and dedicate resources to upkeep them. The savings could be significant meaning satisfied customers.

Technical Writing | What is technical writing and why you need it

What is Technical Writing?

Technical writing is a skill and should you hear a Project Manager or Subject Matter Expert say: ‘anyone can write so “why do you need a Technical Writer?” continue reading.

Technical Writing like many jobs has many facets. The fact you see Writer in the job title suggests to the uninitiated that primarily we write. You could not be more wrong! The writing takes only a fraction of the time allocated to the project.

Let’s get to the point

Our time is taken with analysing content and listening to Subject Matter Experts.

Our Writing is concise and to the point. We are not novelists describing a beautiful character down to her laughter lines. A poorly written novel will not hold the attention of a reader; the same goes for poorly written technical documentation. A user wants to read the document and understand say – the function of multiple servers and Operating systems within a significant infrastructure. Know how to follow a process or service within a few sentences. We can create a document from the viewpoint of the reader by listening to the user and offering document(s) based on the best solution.

Technical Writing is – as it explains in the box – technical. We speak to Subject Matter Experts and translate their language into content that a technophobe will understand.

We produce documentation in several formats in such a way, to get the message across to our many audiences. What I have written – you too will be an expert. Give yourself a hand.

Key elements of technical writing

Using a consistent language with regards to terminology.

Creating Glossaries to help readers understand the terminology used within the document.

Formatting document headers with the same font size and tables and drawings labelled the same way are important.

From using Excel spreadsheets, Template creation, document versioning, documentation content and types of material, clear document titles and subjects – working with either a shared drive or a document management system and talking to SMEs every day your average technical author is a ‘rare breed’ indeed.

If you have not already read my post titled “Technical Authors are not easy to find’ we do not attract many candidates.