Have you ever thought about the role of a technical writer? This booklet based on my Blogs will give you the highs and the lows of the job. You might learn something useful.
To buy a copy click on the link below.
I need a new direction. I am a senior level Technical Writer/Content Writer who has managed medium to sizeable Technical Documentation projects.
I am looking for companies that require an individual to maintain their Technical Documentation, but cannot afford to employ a technical writer full time. Any arrangement will be on a contract basis for a fixed period.
My extensive experience includes OFfice365, SharePoint, VISIO and Adobe applications.
If you would like to speak further regarding your documentation requirements, please contact me.
This book Technical Writing – The Survivor’s Guide is available through Amazon in paperback and Kindle format contains all the Blogs I have written since 2012.
If you want to know how we work, estimate a project, how we view project managers and our role go ahead. Make my day and buy a copy.
As a Technical Author, one question an interviewer asks is what makes a good Technical Author? Based on my 23 years’ experience here is my take on what makes either a poor, a good or an excellent technical writer.
Poor technical writers edit the content and leave it at that. There are no questions, no curiosity even when a set of instructions do not read correctly. In which case, if that is you start looking for a new job.
Good technical writers :
- Logically set out the steps starting at A and avoid no detailed Work Instructions leading to Step Z.
- Methodically test the steps
- ensure the content is easy to read and understood by reviewers
- They know their ABCs
Excellent technical writers go a step further – we:
- ask the question of why – who – what – when – where and how
- analyse the problem the user is experiencing
- ask how the documentation will solve the problem
- anticipate the issues users could encounter and the questions they will ask when they follow the material.
- Build relationships with teams across the floor
- Use humour and diplomacy to get what we want
- Pretend we are a user reading the document for the first time
- include links to related topics to keep the user briefed
All of the above takes time, effort, and creative thinking but as excellence is a byword we never feel the pain.
By covering the above points, the documentation will impact positively on the business. Excellent documentation increases user adoption, reduces the impact on your Support services, and aids your staff should a problem occur that could damage the company and its reputation.
The quality of project management has a direct impact on technical documentation, a fact project managers overlook . This article looks at the areas where the relationship between project management and technical documentation intersect.
Put a plan around a project or a project around a plan
Technical documentation will suffer if the project is floundering without a project plan. A document project without a plan is always at risk of failure. There is a tendency by those with no documentation experience to change the goalposts and and add to the project because in many cases they did not listen to the experience and advice of their technical Writer.
While documentation cannot compensate for the lack of a plan, it can help to revive a troubled project. This method of catching up through documentation will extend timelines, but will serve the project better by mitigating risks and strengthening the overall product through documentation analysis.
An experienced technical writers can certainly find their frustration peaking when the project timeline isn’t workable, or the Project Manager fails to listen to advice. THis happens when:
- working with staff members who have no experience working with documentation and assume its an easy straightforward task
- unworkable deadlines that sacrifice documentation quality and lead to frustration among internal parties
It is worth bearing in mind the following:
- when scheduling technical documentation tap into the TAs knowledge to help plan the timeline for documentation.
- Writing or migrating content is not an instantaneous process; a failure to work with the writers could led to counter productive problems.
- If the timeline is genuinely tight, develop a list of documentation priorities in order for users to adopt the product.
A typical breakdown for a technical writing project includes:
- Research time to learn the project and other elements, such as the underlying technology and related issues required for the documentation effort.
- Dedicated time for writing.
- Dedicated time for editing. copy editing and editing for style, clarity, and other issues.
- Dedicated time to review the technical accuracy of the documentation. Never assume that a document is correct. Always create review time for accuracy by SMEs.
Allow sufficient ramp-up time
Technical writers need sufficient ramp-up time to become versed in the product. While ramp-up time is relative depending on the writer, a project manager can support the writer:
- Provide ready access to necessary hardware and software so the technical writer doesn’t have to waste time waiting on equipment required for documentation projects.
- Provide the necessary system access, usernames, and passwords.
Allow technical writers ramp-up time is more than a learning curve; it’s having the resources in place so they can perform their jobs with minimal downtime, which is billable when they are on-site waiting for corporate bureaucracies to deliver the resources they need.
Review the reviewers
While technical writers must have a stake in the technical accuracy of the documentation they produce, there is often a need for technical reviewers to review the documentation. Take into account this review time in the overall project schedule, including:
- Scheduled time for technical staff, project managers, and other reviewers to go over the documentation.
- Time for the technical writers to add the revisions to the documentation.
Can project managers and technical writers get along?
The documentation component of a project requires 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 better design (because it’s documented), and better customer support through documentation. A self-sufficient customer who doesn’t call customer support is like money in the bank for your company.
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