Technical Authors what we are and what we are not

Whatever your view of a Technical Author, do not be fooled by that title. We are much more than people realise, and we can help in ways you never thought possible. So, let me bust the myth about what we are and what we are not.

Would you mind reading on? 

What I or WE are NOT

Software developer

If I knew BASIC, C/C++, Java, you know where I’m going, I would be earning far more as a developer.  I receive many calls for API documentation, a niche skill requiring knowledge of the code used in an API.

Project Manager

I will be careful here. I am not a project manager certified through Prince2, Agile Scrum, etc. My PM skills are relevant to technical documentation, whereby I set my schedule and arrange meetings with SMEs and other stakeholders. 

Beyond documentation, my PM skills do not stretch to:

      • the provision of detailed project planning, including progress evaluation, risk management, issue and resolution. If that is essential, hire a full-time Project Manager.
      • A secretary organising the working lives of colleagues,  and taking minutes. I do record my meetings (with a dictaphone) and extract the relevant information for the documents.

Technical Authoring on its own is a time-consuming role, and any expectations from me over and beyond the documentation scope of the project might be pushing my ability to get things done in a timely matter. Remember, our skill is documentation and how to fill those documents with information. 

I can 

Sit with your SMEs and open their heads to extract all that hidden information. I then use it to build a document explaining to your non-technical audience how it works.  

While I will be familiar with the terminology, remember I am not an expert in your department. I learn on the job. 

I do supply effective written / verbal communication and collaboration, sympathy and encouragement to get things done. It isn’t as painful as people think.

I’m a third party

As an external consultant, I make decisions after a period of reflection on your situation and your expectations using MoSCoW. That stands for four different categories of initiatives: 

      • must-haves, 
      • should-haves, 
      • could-haves, and 
      • will not have. 

The “W”, should you prefer, can mean wishful thinking

Let me have it

When I join, please throw your documentation at me, everything, wherever it is and let me sift through it all. I have my own excel spreadsheets to track and control the documentation.

While I am at it, I suggest analysing SharePoint and/or Confluence and define exactly how your teams will manage the documents/content. 

The efficient management of both applications improves the flow of information available to your teams.

By now, I know where the knowledge gaps are, where I can improve the documents and start working with your SMEs. 

Project Management 

As mentioned above, I do possess the relevant skills within the context of a Technical Author. 

      • Design new template
      • Improve structure of existing documents
      • Process documentation across several categories,
      • Arrange meetings with SME’s,
      • I use tried and tested methods to plan, write, review, publish and maintain the content.
      • Write/update the documents.
      • Procedures and processes updates,

An aid to Content Development

With over 23 years of experience behind me, I already own an extensive library of generic documentation and various templates. If you have no documentation, we can tweak any document to meet the profile of your business. It saves not only time but also money. 

ITIL and ITSM

I have experience in producing the following document types: 

      • IT Service Management (ITSM) based on ITIL best practices. Level 1 to 4 BPMN VISIO Processes and Narratives.
      • Service Design, Service Transition, Service Operation and Continual Service Improvement,
      • Delivery and Service Support, 
      • Availability, 
      • Capacity, 
      • IT Service Continuity Management; 
      • Incident, 
      • Problem, 
      • Change, 
      • Release, 
      • Configuration Management and 
      • Service Desk.

Policy and Process

      • Delivering written Policy, Process & Standards
      • ISO27001/9001 compliance documentation to support a company’s GDPRPCI/DSSSecurity project
      • documentation to support a Disaster Recovery scenario

Infrastructure Documents

      • Operating Infrastructure documentation to support the functions of a large-scale Network
      • A suite of documentation to help IT teams manage the pre-migration and post-migration stages of a Cloud-based service program.

Editing Existing Content

Enhancements may include: 

      • adding VISIO drawings,
      • new screenshots,
      • reword policies and content per se,
      • additional narrative to Processes that are light on information,
      • new templates, and
      • Structure to existing Word documents and consistency. 

All information needs a peer review by people who should know the data best and provide feedback. I leave nothing to chance to get what you need in place. 

Tools

Apart from Spreadsheets, MS Word, PowerPoint, VISIO, my skills keep these projects on track. I will also suggest ways in which you can keep the documentation up to date and current. Information is an asset, and without it, you could place the business at a disadvantage.

SharePoint and Confluence

Suppose you have no official documentation strategy or a means of managing the documentation. If so, let me create a plan that will work for you. Documentation needs to be available to all staff and needs to be updated, rewritten and archived appropriately. Other aspects that need managing are ownership, version control and historical control.

If the business uses Confluence, my experience is an overload of outdated content no longer relevant to the company. I can analyse all spaces and check when the content was written and submitted. 

Expectations

Too many to mention, but the immediate impact will be on the following three points:

      • Reduced costs
      • more responsive Help desk/support 
      • better informed staff
      • Confidence performing procedures.

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

 

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.

Technical Writing | Hire a Technical Writer sooner, rather than later

As a Technical Writer with over Twenty Years of experience, I have a question for Project Manager. Have you ever planned a project (PCI, GDPR, ISO27001, ITIL) where documentation is critical; if so, how did it go? Crucially, did the project deliver ALL the documentation? If not – do you know why the plan failed?

First: Did you speak to a Technical Writer for a realistic appraisal of the expected outcomes?

Second: was your budget a few pennies short?

A collective failure of technical / process documentation projects is the lack of knowledge and expertise during the planning and discovery phases. Many project managers do NOT grasp the reality of a documentation project.

The planners do not understand the lifecycle of a document. From the initial draft through various reviews and sign-off takes much longer than expected.

If the PM does NOT know the difference between a written process, a documented plan, and the purpose of a policy your project could be in trouble.

How long to write a document? My default answer is “I do not know”. Technical and process documentation depending on the project (PCI, GDPR, Operations, ITIL) will have many requirements and factors which delay the following stages:

      • the information gathering,
      • the writing,
      • review stages, and
      • sign-off.

The likely reality of writing a 30-page A4 process document containing:

      • VISIOs (3 or more) comprising between 10 to 30 steps
      • Process narratives (3 or more) of between 10 to 30 steps
      • Appendixes (2 or more)

Will  take at least 8 – 12 weeks of effort before reaching the review stage. My advice is not to plan such a project without professional help.

Compliance projects such as PCI and GDPR generate a lot of documentation. If you are starting from scratch, the list of required documents could exceed 60 or more.  In timing terms you are looking at 12/18 months of work or more. If you have partially written documents, DO NOT expect timings to diminish to a few months. Your project faces a lengthy overhaul as a technical author will attempt to get the documents into a consistent state. Finally, to succeed there must be management buy in. Without t the TA will struggle to muster the help. Any failures will multiply costs.

Hire a Technical Writer

My advice is this – If you have a project that requires documentation, hire a Technical Writer, not a Business Analyst, for advice from the start of the project, NOT when the end date is in sight and the budget is running out. The TW can highlight issues, risks, and bottlenecks and help you manage expectations within the allocated time assigned to the project.

The Technical writers will need:

    • a week (at least) to assimilate the project
    • Time for training on any tools
    • access to Subject Matter Experts (SMEs)

Add in contingencies for illnesses, holidays and unplanned absences, and the fact a TW could resign from the project at some point.

If the budget and the timelines become fixed (in stone) with multiple documents to complete in a short period, then produce quality, rather than quantity.

To ensure quality, rank the documents across the set:

    1. Required
    2. Nice to have
    3. Not important

Or use The MoSCoW method.

    • M – Must have this requirement to meet the business needs
    • S – Should have this requirement if possible, but project success does not rely on it
    • C – Could have this requirement if it does not affect anything else on the project
    • W – Would like to have this requirement later, but delivery won’t be this time.

Additional Points

    • Travel: Will the TWs need to travel abroad or Nationally.
    • References: Identify any useable archived documentation.
    • Reviews: decide who will review and who will sign off a document
    • Scope: Could there be any changes which will add to, or change the scope of the project

In summary,

Documentation projects fail due to:

    • poor planning
    • the lack of experience and
    • not allowing enough time to complete the documentation.

Finally: If the success of the project depends on the documentation (Disaster Recovery Plan, PCI/DSS, BCP and ITIL) – why do PMs and SMEs allocate so much of the budget to non-documentation resources?

Technical writing | Now that you have Technical Documentation

So, after the initial shock of discovering what happens when you have no technical documentation, what can you achieve now that you have technical documentation?

1: Have you employed/contracted a Technical Author . . . Great!! If not what’s holding you back . . . remember we bring value

2: If you cannot see your technical author at their desk you’ll no doubt find him/her performing Vulcan mind melds and extracting the necessary technical information from the heads of your development/infrastructure staff (if it looks painful don’t worry, the job is mandatory!)

3:  Start a discussion about what you need and I’m certain your technical author will only be too happy to help?

4: Once you have technical documentation there is no more guesswork as you have plenty of reliable data against which to measure the progress of future projects

5: You can also employ a project manager who can plan ahead because you know everyone who needs it!

6: Documentation is no longer a problem and what you require is what you will get . . . Congratulations!