Technical Writing | General Data Protection Regulations


On the 25th May 2018 the new General Data Protection Regulations (GDPR), will come into force. Despite ongoing BREXIT negotiations, due to end in March 2019, the Information Commissioner’s Office (ICO) has implied that the UK will enact GDPR.

Companies outside the EU

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

Compliance and documentation

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

To comply, you MUST write and maintain a set of Policy, Process and Plan (PPP) documentation. It will ensure you have evidence to support your claims should the ICO investigate.

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?

There is a lot of advice available on the web regarding GDPR. However, there is one piece of advice many may have overlooked. That the project could be a lengthy and costly exercise. The review process is continuous because the PPPs will need updating in the years to come.

During a recent conversation with an employment agent, he made a point which many businesses are overlooking and that is the projected costs of complying with GDPR. Drafting in Project Managers, (costly) Consultants and Business Analysts to manage the process will be expensive. The budget needs to be set accordingly.

How to get started

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

GDPR, or Bust? Time is running out and if you have not made up your mind how to proceed, then you need to do so quickly.

Some useful snippets such as Exceptions

If you have

  • more than 250 employees, you must document all Processes
  • less than 250 employees, only document `Processes that:
  • if the processing could result in a risk to the rights and freedoms of data subjects, or
  • the processing is not occasional, or
  • the processing includes special categories of data as defined in GDPR Article 9.

The Main GDPR Articles

  • Statements of the information you collect and process, and the purpose of processing (Article 13 of the GDPR).
  • The Records of consent from data subjects or relevant holder of parental responsibility (Articles 7 and 8 of the GDPR).
  • The Records of processing activities under your responsibility (Article 30 of the GDPR).
  • Documented processes for protecting personal data, such as an information security policy, cryptography policy and procedures, etc.

Finally, I leave you with the following:

  • Breaches in data security must be reported immediately to data protection authorities such as the Information Commissioner’s Office (ICO) in the UK. Ideally, breaches should be reported within 24 hours if possible but at least within 72 hours.
  • Failure to comply with the will lead to penalties. Under current rules, the UK’s Information Commissioner’s Office (ICO) can fine up to £500,000 for malpractice but under GDPR penalties could be more than €20 million or 4 percent of annual turnover (whichever is higher).
Does Your GDPR Project need documentationClick To Tweet


Posted in Document management, Documentation, GDPR, Process Documentation, Technical Writer, Technical Writing | Tagged , , | Leave a comment

Technical Writing | Project Managers and Technical Writers

Can project managers and technical writers get along?

I always make the point to Project Managers that Technical Writers are highly organised. They juggle numerous tasks and switch between them with ease. They also have great people skills working with coders, engineers, and technicians of various shades. In the meantime, they manage a ream of documentation while taking instructions from SMEs. Occasionally a project manager who has never had to consider technical documentation as part of a project offers advice.


Project Managers and Technical Writers


The technical documentation component of a project does require input from technical writers to help ensure quality technical documentation. A working collaboration between project managers and technical writers can help organisations reap the benefits of the project (because it’s documented), and better internal and external support through documentation.

If you are one of the many Project Managers who has never worked with Technical Writers, bear in mind that we are professionals.  We will not tolerate the viability and quality of the technical documentation to satisfy the needs of others.


Project Managers and Technical writers

So, if you have no direct experience with documentation or Technical Writers consider the following:

  • Take time to 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.
  • TWs cannot pull documentation from a hat or generate a document from code.
  • 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 the timelines or worse underestimate the deadlines. Always build in flexibility to allow for problems in the documentation process
  • Reviewing a document intended for transformation containing more than 20 pages plus will take time (the general rule of thumb is one hour per page).
  • Time required for writing
  • Peer reviews
  • Time to have the content technically reviewed
Posted in Technical Documentation, Technical Writer, Technical Writing | Tagged | Leave a comment

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 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.

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)


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


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

In my opinion, using the active voice, sentences provide a clearer more effective message in technical writing and business writing. The active voice clearly identifies the action and determines who performs that work. For clear examples of passive voice take a 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.

Posted in Documentation, Technical Documentation, Technical Writer, Technical Writing | Leave a comment

Technical Writing | Interviewing SMEs

Without Subject Matter Experts to impart their knowledge about their technologies writing that content will be a harder job. So, how does an experienced technical writer consider approaching and interviewing Subject matter experts?

I base my advice on my personal experiences of talking to and working with SMEs. You will no doubt find, like me, that some SMEs are difficult while others are happy to help.

Approaching and Interviewing  Subject Matter Experts 

  1. Make sure you schedule a meeting with the SME in advance, do not turn up at their desk and expect to talk. Most SMEs are busy and might be working on an important task.
  2. Make sure you know the SMEs area of ability and their role within the company
  3. If you collaborate with other technical writer’s check any project management plans or ask if they have already spoken to that SME
  4. If yes check the information to see if it is relevant to you. It will save time asking the SME twice for the same information and prevent any stern reminders that they have already discussed ‘XYZ.’
  5. I use a dictaphone to record interviews because it means if I have any queries I can always run the recording back. 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 object, it will mean listening intently and writing down the information
  6. Approach the Interview at the appointed time:
    • Do not be surprised to find the SME cancels the meeting due to other demands
    • If so, reschedule the meeting
  7. Always regard the interview as another knowledge capture exercise, which adds to your experience, do not assume you know everything before you get there, even if you do.
  8. The SME will assume that you know what they are talking about; if not – stop the interview, and either request a less technical explanation or if you still do not understand then you need to reassess your ability to do the job.
  9. Only schedule an hour for the interview but make it clear that if there are any points which are not clear, you will need to reschedule more time
  10. Be clear – there will be a peer review required, but you will let them know in advance when the document is ready for review
  11. 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 introduce the project and you if you have not already done so introduce yourself

  12. The SME may not know everything and may need to refer you to another SME for information
  13. When you return to your desk, start writing up the document. Do not wait for a few days, even if you have recorded the interview
  14. Carry a pad and pen. You may need to ask the SME to draw the infrastructure
Posted in Documentation, Process Documentation, Technical Documentation, Technical Writer, Technical Writing | Leave a comment

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 two interviews; one in Watford and Cambridge. Both were software companies looking for a Technical Writer. Neither interview went to plan as in both cases the interviewer seemed distracted and uncertain what to ask.

When the respective agents called with the feedback, both companies followed a similar route. To keep costs down they appointed an internal resource.

Later that year I received a telephone call to tell me that the Watford company after a management buy-out sacked the TA. His documentation failed to meet standards. I was later told that the Cambridge company began to search for an experienced Technical Author after the internal appointment failed to deliver.

The third situation arose when a previous client called. One of their technical writers had left with work to complete. Once I analysed the work, I made it clear that 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 technical writers will point out that you get what you pay for. Be ready to pay the going rate to attract an experienced technical writer who is more than capable of doing the job. You also need to consider our role is not as straightforward people think. There is more to the job than an amateur might think.

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.

Posted in Documentation, Technical Documentation, Technical Writer, Technical Writing | Tagged | Leave a comment

Technical Writing | Sourcing a technical writer

When sourcing a technical writer, you will need to ensure that their experience matches your requirements. It goes without saying that you need to source one who has the right knowledge, background and expertise. At the interview they should aptly demonstrate that experience by way of samples; if not 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 tenure, the broader and more in-depth their experience will be. However, the only way to be confident is to read their CVs carefully.

Do they use Social Media or have a website?

Check out LinkedIn for their profile; If you cannot find one 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 may offer suggestions on how to elevate the project with innovations you may not have considered.

Read the CV and be prepared to discuss the project. I have arrived at an interview to find the interviewer has not read my CV. I have a simple rule regarding my experience; if you cannot see it on the CV, then I have not done it. That does not mean that I will turn down unfamiliar tasks.

Effective communication

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

Do you want a contractor or permanent TW?

You may be building a team, and you need a Technical Writer to keep the documentation up to date; a person who will grow into the environment. However, I would caution against employing a Technical Writer on a permanent basis unless you are sure there will be ongoing work.

Work cycles can and do 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 to shift boxes and to clean the stock room and 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 the odd spurt of activity within the working life cycle. In my opinion, this is why the position of Technical Writing lends itself more so to contract work rather than permanent work.

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

A word of caution

Unfortunately, our profession can and does attract its fair share of triers. You can reasonably expect CVs from candidates who have had minimum experience preparing ad-hoc documentation. Unfortunately, that minimal experience will NOT be enough to perform the job.

Many recruiting agents have 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.

Applying the following advice may help you avoid problems:

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 means the Technical Writer’s experience may be severely limited. That also goes for junior writers. For high profile projects hire a seasoned contracting professional, who can talk through the project with you. In my experience, there is a world of difference between a contract Technical Writer and one who has chosen permanency.

Finally, when it comes to budgets ensure you are buying the experience you need. In the world of Technical Writing, the price you pay determines the standard you buy. By employing the wrong candidate could be a costly mistake.

Where else can you source a Technical writer?

If you prefer to source a Technical Writer, you have found me.However, I may not be suitable for the role. Check LinkedIn, Social Media sites and the 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 which in the long run could save you money.

Posted in Technical Writer, Technical Writing | Tagged , , | Leave a comment

Technical Writing | The risks of poor document management

The risks of poor document management stem from managing multiple types of documents in different formats, workflows and updates. If the documents, which are in constant use have no defined structure it will lead to an uncontrolled and unmanaged repository. This haphazard approach to managing the document Lifecycle impedes employee productivity.

The scenario is this: you are sitting at your desk when your boss requests the latest version of a critical policy document. When do want it you ask?

The risks of poor document management

The risks of poor document management

Now is the reply as she has an urgent meeting. It is located on the company’s shared drive. Your search starts with your department folder.  However, it is not there. You decide to perform a search and type in the title. Your face falls flat when the search returns 100s of potential matches. You open up the most likely and find they are not current.  Panic sets in and your boss is now calling your desk phone, as she is late for her meeting.

We have all been there, as intuitively as we think we have organized our company “shared” network folders, documents get lost and frustration sets in. Whether it is neglecting to archive or delete the outdated version of documents, images, files, assets, etc. or employees using confusing naming scheme for the folder structure – the point is this archaic means of organising and managing documents/assets isn’t working for your company and it is costing you.

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

  • Diminished document utility
  • Decreased business efficiency
  • Increased operational risk and cost

Effective Lifecycle management

The management of Documents continues throughout their useful lifespans ensuring businesses meet compliance and regulatory requirements while preserving the productivity of employees and agility of business processes:

  • Quick access
  • Frequent review and updating
  • Distribution
  • Conversion
  • Archiving

Document management

The risks of poor document management

The risks of poor document management

If your document library is growing with no control consider creating a Document Management library to store and manage your documentation.

The growing influence of ISO and ITIL requires documentation to contain elements which relate to its History, Versioning and sign off, all of which are easy to incorporate. Going forward your staff should know how to manage the documentation in the absence of someone dedicated to the role.

Posted in Document management, Documentation, Technical Documentation, Technical Writer | Tagged , | 1 Comment

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.

Posted in Disaster recovery, disaster recovery plan, Documentation, Technical Writer | Tagged | Leave a comment

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 bypass a proven way to cut back on calls to the Helpdesk. No doubt many helpdesks provide an excellent service and manage the demands of the users. The problem with most technical documentation including user guides is that it is incomplete and full of gaps. Documentation needs to flow and provide practical tips on how to get the best from the software.  If your customers had well written and comprehensive documentation you could substantially cut back on costly calls to your helpdesk.

Technical documentation vs Helpdesk

technical documentation vs helpdesk

technical documentation vs helpdesk

I have experience in manning a premium line Helpdesk and have spoken to many angry customers whose subjective complaints about the company and the guilty software lead to comments such as:

  • 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 fails to 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.  To facilitate their requirements, I created a feedback option to enable internal and external users to point out where the documentation appeared vague.

The developers and helpdesk provided a more detailed solution based on their knowledge and experiences. I created a 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

Always treat your documentation and your information as an asset’ and invest in the necessary resources maintain the documentation. The savings could be significant meaning satisfied customers.

Posted in Helpdesk Support, Technical Documentation, Technical Writer, Technical Writing | Tagged , | Leave a comment

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.

Posted in Documentation, Technical Documentation, Technical Writer, Technical Writing | Tagged , , | Leave a comment

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

As a Technical Writer with over Twenty Years experience, I have a question for Project Managers and Subject Matter Experts. Have you ever been involved in planning a project (PCI, GDPR, ISO27001, ITIL) where documentation is critical; if so, how did it go? Crucially, did the project achieve its aims of delivering ALL the documentation? If not there is a good reason to Hire a Technical Writer.

Why Hire a Technical Writer?

hire a technical writer

Technical Writer

A collective failure of technical / process documentation projects is the lack of knowledge and expertise during the planning phases. Many project managers and Subject Matter experts fail to grasp the reality of a documentation project. Many projects fail miserably because 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. I regret to say I have met PMs and Consultants that do NOT know the difference between Processes and Plans and Policies. If that is the case your project could be in trouble.

How long to write a document?

If you ask a Technical Writer how long will it take to write one document, their reply will be – “I do not know”. Technical and Process documentation depending on the project (PCI, GDPR, Operations, ITIL) will have many different requirements and factors which delay the information gathering, the writing and review stages before sign-off.

This is the likely reality: a 30-page document containing:

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

Will amount to – give or take – at least 10 – 15 weeks of effort before it gets to the review stage. However, the more content and complex the document becomes, the longer it will take.

If you are wondering why it takes so long – it is worth noting that compliance projects such as PCI and GDPR generate a lot of documentation. TWs working on large projects could be managing a list of more than twenty documents and every document regarding size and content could be very different.

Hire a Technical Writer

My first word of advice is this – If you have such a plan on the horizon, where the Technical / Process documentation is the primary focus – hire a Technical Writer, not a BusinessAnalyst, to give guidance from the start of the project, NOT when the end date is in sight. The TW can highlight issues, risks and bottlenecks. You will also know what you can reasonably expect to achieve 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 due to personal reasons 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, consider producing Quality, rather than Quantity.

To ensure quality prioritise, or rank the documents to avoid inconsistency across the documentation 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


Who will use them?

  • Documents for external and internal users will require a different level of language
  • What level of information and detail will the audience expect?
  • Does the document need VISIOs?

Additional Points

  • Travel: Will the TWs need to travel abroad or Nationally, if Yes, are they available to go and do they have current Passports/Visas?
  • 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?

Posted in Documentation, Process Documentation, Technical Documentation | Tagged , , , | Leave a comment

Technical writing | Keep SharePoint working for your Business

Companies pay premium rates to have SharePoint installed only to discover their staff continues to use it as a glorified shared drive. So, how do you stop SharePoint from becoming a free for all?

Allowing users to use SharePoint without control raises problems around folders because they create:

  • new multiple folders with obscure titles
  • folders which remain empty
  • which eventually leads to complaints that users have lost their documentation.

In other words, the users created folders that remain empty because they cannot remember:

  • where they placed the folder
  • the title of the folder, or
  • no one writes the documentation

What is the problem when users create multiple folders?

  • You cannot navigate through multiple folders in SharePoint
  • A hierarchy of folders means some users will give up searching after drilling down through multiple folders to find a set or a single document
  • Creating multiple nested folders can quickly hit the maximum number of characters (255) for the URL.

Streamline SharePoint with library names that are meaningful

Create a new site name and library name and delete any out of the box “Shared Documents” libraries (don’t just edit the name).

Note: When creating any list or library for the first time, keep the name short. You can later edit the title for display in the breadcrumbs. The symbol [%20] will not appear in the URL whenever space is used in the name.

Use the library description field

Describe precisely the purpose of the library.

  • Is it restricted to a particular group of users?
  • What types of files should the library contain?

Example description: “This library stores ITIL procedures. Contact the infrastructure team for advice.”

  • use Metadata categorisation to simplify navigation making it easier for users to navigate multiple document libraries, RATHER than multiple folders.
  • Expanding categories to display contents makes it easier for users to see the document content. The Proper terminology for the types also helps simplify search.
  • It is not easy to rearrange a library with multiple folders due to growth or changes to business processes, so the planning and categorisation of uploaded documents can help minimise time “rearranging” files for long-term planning.

User Adoption Tip: Through Customisation, restrict or remove the user’s ability to create new folders. Remove the Explorer view else users can still create folders.

If you need to have one library containing different levels of permissions, then you can set permissions on a folder. Although you can set permissions at the document level, it creates many other challenges in managing security and is best avoided whenever possible.

Enable versioning and history on official and formal libraries

  • The check-in/check-out capability of SharePoint helps users manage documents and prevent users from altering checked out documents.
  • When a document is checked in, SharePoint gives the option to create either a major or a minor version of the document.
  • Version history outlines modifications and who modified it.
  • Using major and minor versioning helps users identify a new published major version
  • Consider displaying the version in the view as well as the last modified date, modified by, and checked out by for user convenience.

Place a limit on major and minor versions to optimise storage space

  • Each time you save a version of a document, it creates a copy.
  • Setting proper version control can optimise your disk storage space.
  • Set-Up version control that saves the versions you need

Example settings: Keep major versions and the three most recent minor versions OR keep the five most recent major versions, and all minor versions of the final major version.

Ensure the content owner of a site has the capabilities to change library settings

Each SharePoint site should have a Site Owner and a Content Owner. Grant the Content Owner the permissions to change all the settings on the library, except for permissions to eliminate contacting the Site owner every time they need to make a change (build a new view, alter metadata, etc.). In the absence of a compelling need, there is no reason to give them full Site permissions; however, to promote an efficient work environment they should be able to manage their changes within the library settings.

Manage security at the site level when possible

Where possible, permissions should be the same for all content on a site. SharePoint allows you to have different permissions on each list/library and even different permissions at the item/document level. Unless you have a 3rd party solution to help you manage permissions, this will become unruly very quickly.

If you need to restrict access to a few documents, create a folder with permissions, which works if the document tags are the same. Once again, this is an exception, not a rule!

If the documents need different tagging, create a new library with the required tags and permissions. Ensure that the library description states the restrictions. If you need more lists to go along with the library such as a task list, issues list, etc., then you would consider a new site. 

  • Limit each Library View to 1,000 Documents to Optimise Page-load Time
  • Enable Content Approval only on the Libraries that genuinely need it.

When you place content approval on a library, any changes to the existing documents or recently uploaded documents will not be displayed to the group until they are approved. The ability to see changes in real-time are therefore limited. TO maintain an active area of collaboration DO NOT turn on Content Approval.

Use Content Approval for Public Libraries where a variety of users have access to posting documents, where the accuracy of documents is vital for public consumption. An example of a library that may need Content Approval is an HR Policies library.

Designate ownership

Designate a document controller who can control the documentation loaded into SP

Keep SharePoint working for your BusinessClick To Tweet
Posted in Document management, Documentation | Leave a comment

Technical Writing | A brief guide to documentation projects for Project Managers

A brief guide to managing documentation projects for Project Managers will demonstrate that when done correctly will produce long-term benefits.

Here are some examples to help keep your documentation on track.

The original writer is not the best person to check their documentation because they very rarely spot their mistakes.

  • Arrange for a peer review and/or technical review of all changes
  • establish a review process to make sure the documentation is both factually correct and consistent.

All documentation requires ongoing review once or twice a year.

  • If your company use a Document Management system to store documentation, make use of the “metadata” windows to describe the content changes to make the review process easier and consistent.
  • If you are so inclined adding an index to your document, especially when it is a large document will enhance the documents usability

Like everything else, documents become living information that:

  • Maintaining the documentation represents a significant challenge
  • Without a management policy or agreed procedure, the Documentation you are creating will cease to have any value if it is not updated
  • Documentation requires dedicated resources, in which some companies will not invest
  • In other words, use or contract an experienced Technical Writer
Posted in Document management, Documentation | Leave a comment

Technical Writing | Why your business needs Technical documentation

Managers underestimate the purpose of technical documentation until they discover they have no relevant documentation. Listed below are 6 reasons why you need technical documentation

  1. Without technical documentation you have no historical record of any project ever completed within the company
  2. You have no metrics against which to measure current projects
  3. You have no information which outlines the lessons learned and the lessons failed
  4. During an upgrade project the team relies on guess-work to get things right . . . it also means the project will take much longer to complete stretching the budget
  5. What documentation there is lies scattered over several drives and only makes sense to the author
  6. Your valued tech staff have left the company taking information with them in their heads

Now you know why Technical Documentation is important; if you recognise one or more of the points above . . . what’s your next move?

Posted in Documentation, Process Documentation, Technical Documentation, Technical Writer, Technical Writing | Leave a comment

Documentation projects, before, during and after

Documentation Projects

Many Project Managers and Subject Matter Experts fail to understand the challenges posed by documentation projects. To lead such a project, you need to know what is important and how you will achieve the goal. What preparations should you make to ensure you complete the project within budget?

Here follows the best advice on the documentation projects, before, during and after.

There are many types of technical and process documentation. If the project is compliance based (PCI, GDPR) concentrate resources on the documentation. Consider hiring a Technical Writer quickly for advice.

Capture the data/content

  • Check the availability of the Subject Matter Experts as well as other team members critical to the project
  • Consider the audience for the documents as that will determine the level and detail of the material.
  • Remember the level of content and information is only as useful as its source and the ability of non-technical audiences to use and follow the instructions/processes

Organise the document and content

Create a standard template with Heading and instructions regarding the level and type of material the TWs need to gather. As a guide use the following headings:

  • Work History
  • Versioning control
  • Scope/Out of Scope
  • Document Purpose
  • Document ObjectiveIntegrate Level 1 to 3 Headings to outline the topics.
    • You can base these decisions according to prerequisite documentation knowledge to provide the master plan for all future written work.
  • Does it require VISIOs/Screenshots?
  • Appendixes

Do NOT waste time creating project timelines to write and produce the documentation.

Until the information and gathering phase begins, do not even consider a guess about how long it will take to complete the documentation.

As the list of titles grows, Management may need to consider extending the budget to finance the project. Abandoning the documentation when it is ‘Nearly there’ will be waste of money, time and resources.

Decide the output format

When the Technical Writer has written the documents, consider which of the following formats will suit the company’s requirements.

  • MS Word stored in a Document Management System
  • PDF stored in a Document Management System
  • *.CHM files created by using such application as RoboHelp
  • Wiki formats: A Wiki provides the user community with the opportunity to provide documentation feedback

Future Review Requirements

Do not overlook the future requirements of any project. All documentation is an ongoing project. Establish a workflow between the IT teams/Process teams and the documentation department to update documentation.

  • Update the documentation when:
  • the IT teams upgrade or modify the Server/Application/technology
  • document all changes, using a change management process to prevent any repeat the configuration
  • align the documentation and the project

Revise the Project

On completion of the project Use the documentation to:

  • reflect the changes and updates
  • test to ensure instructions are clear, concise and correct
  • Avoid considerable time, frustration, and future expense by correctly applying documentation strategies to:
  •  . . . ensure that users can follow the instructions
  • . . . provide a historical record of the changes made during the project
Manage documentation projects before, during and afterClick To Tweet
Posted in Document management, Documentation, Technical Documentation | Leave a comment

Technical Writing | The cost of Technical and Process documentation

Why is it that companies view the cost of Technical and Process documentation as an unnecessary expenditure rather than viewing documentation as a centre of knowledge? Management seems to have a blind spot when it comes to documentation and conveniently forgets the role of documentation.

When redundancies beckon, I know how quickly the technical documentation department will be sacrificed. When management seeks layoffs, the technical author(s) will be amongst the first out the door. Months later a member of staff points out that the documentation is out of date and follows up by asking: do we have anything up to date we can use?

In sacking the technical documentation team, no one assumed responsibility. Keeping it up to date is left to those least inclined to keep it up to date. They are the people who would benefit most from its upkeep.

The cost of Technical and Process documentation

The cost of Technical and Process documentation

Within a software environment, we easily forget that as the developers progress their software application, it also becomes more complex. Failing to supply up to date documentation means customers can and do overlook many of the improvements and advanced features. The same could be said of any IT department. As the network grows, there are more questions and fewer answers. No one has a good overall knowledge of the network due to the lack of documentation.

Where does that leave technical writers?

However, you refer to us, be it technical authors, communicators, documentation staff or as the font of all knowledge. Never doubt our experience, our people skills, our ability to write clear instructions.  We can explain complex technical terms in easy to read formats. Who else is willing to put up with blank stares, sarcastic comments and listen to comments such as “whaddya want now?’ to get what your company needs; usable documentation.

The cost of Technical and Process documentation

The cost of Technical and Process documentation

Remember it is not about the cost of hiring a technical author. It is about our value to your organisation. Our documentation will keep your staff informed and up to date. There is a point to keeping your processes up to date as your working environment changes. It is also about keeping that software guide up to date enabling your customers to use your product more efficiently and know they invested in a superb product.

Finally, don’t forget that a technical author will not only you save money now but also at a later date and will keep on saving you money, therefore, over the long term justifying their value to your business.

The cost of Technical and Process documentationClick To Tweet

Posted in Document management, Documentation, Process Documentation, Technical Documentation, Technical Writer | Leave a comment

Technical Writing | Hiring a Technical Writer

Budgets for the job

When you start the process of Hiring a Technical Writer, my advice is thisdo not cut corners when sourcing a budget:

  • Check the daily rates/hourly rates. Do not expect an experienced technical writer if the daily rate is derisory.
  • If your rate is low, you will attract Technical Writers with less experience whereby the result could be a disjointed document with no formatting and poor English
  • A good TW who charges a higher rate may save you money by taking less time to do the job.

Your Technical Writer in the flesh

hiring a technical writer

Hiring a technical writer for your project

Many TWs will have worked in a variety of environments. In due course, we gain knowledge that could provide a solution to other long-running problems. Hence why managers should never underestimate TWs.

What will you need?

Before you actively engage the TW on your site, do you have all equipment ready:

  • One of the most common problems is no laptop on the day they start
  • That their profiles to log in to the network are set up
  • If they are reviewing existing documentation make sure it is available

When you start explaining the work to a TW in company-specific jargon, do not assume they understand you. There is a good chance that the TW during an interview may mention that what one company knows as “XYZ” may not be the same as yours.

What should you do?

  • Be certain the SMEs or others with whom the TW will engage are aware of the appointment and know the goals of the project
  • If you are the primary contact do not disappear without the TW knowing where you are or who is second in command
  • Do not assume the TW is less than proactive if you cannot see them writing down a list of questions and talking to the appropriate people. If they are reviewing existing documentation, they may need a few days to understand the content before they start acting pro-actively
Techwriting Hiring a Technical Writer

Hiring a Technical Writer

If after settling on a start date

If a problem arises let the TW know in advance because:

  • You may need to change the start date or find another job for the TW to assess.
  • Delays will only diminish your budget if the TW is on-site with nothing to do.
  • If the problems are likely to be ongoing be honest and let the TW know – do not consistently change the start dates because it is not very professional and TWs do talk to fellow TWs.
  • Be consistent with the project, its objectives, and deadlines
  • Do not change the parameters of the project by allowing project scope creep.
  • Communicate with the TW as S/he may not have the time to stay beyond the current time allotted for the project.
  • Make contingencies if you need to extend the contract

What will the Technical Writer do for you?

Supply a project plan. Do not expect one within a matter days. if they own a generic copy, they can adapt it for the project; else create one from scratch.

The project plan should include a documentation schedule, including milestones and how progress can be measured.

On longer projects, TWs will complete a weekly project management report, which will outline problems, issues, bottlenecks, etc.

If the contract states that travel abroad or within the UK is necessary, make sure they are available to go.

Foreign travel as part of the contract

Some companies expect contractors to pay their expenses up front on foreign trips.

Might I suggest that they:

  • Can afford to do so without getting into debt.
  • Know the procedure to claim their expenses
  • Be clear on when the payment will be paid
    • I once submitted expenses, which, due to a misunderstanding took three months to process.
Posted in Documentation, Technical Writer, Technical Writing | Tagged | Leave a comment

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!

Posted in Documentation, Technical Writer, Technical Writing | Tagged | Leave a comment

Technical Writing | The Problem with Shared Drives

It is not unusual to find companies still use Shared Drives to store their documentation. As many Technical Writers will point out, the problem with shared drives is that they are neither secure nor searchable.

What is the problem with shared drives?

  • The folder structure has too many levels meaning documents are difficult to find
  • There are information gaps as users keep copies of documentation locally and not on the shared drive
  • There is no formal ownership of the documents
  • The title and subject of the document does not accurately reflect the content
  • Document versioning is not used meaning the latest version is  . . .  Where?
  • There are many copies of the same document
  • The failure to maintain a workable Archiving policy means many documents with the same title contain unchecked updates
  • There is no historical tracking of documents to keep integrity of the content
  • Searching for documents on a shared drive will raise many unrelated results

Using a non configured Document Management System (DMS)

It would seem ironic that companies do spend a large amount of budget on installing a DMS such as SharePoint but fail to task an experienced employee to set it up correctly. So what happens when the DMS is left to grow without the correct administration?

  • Failure to lock down user privileges means it becomes a free for all  with no proper administration
  • Check In, Check Out, Document Versioning and Security are not configured meaning user’s drop off documents where they see fit
  • There is no historical tracking of documents to keep integrity
  • Users create folders without proper titles and lose their document
  • Backup of the DMS is irregular

If you want to manage your documentation in a way in which it cannot become a free for all you need to consider a form of document control and establish a policy and a set of rules to keep your documentation in check.

Technical and Process Documentation is an asset, and your staff should treat it as such. Look after it, and it will look after your business.

Posted in Document management, Documentation, Process Documentation, Technical Documentation, Technical Writer, Technical Writing, Uncategorized | 2 Comments