top of page

Why should you never (hang on! actually always) hire a Technical Writer!

I want to share one of my many interesting experiences in the project world. I was working on a project rolling out a cloud computing product. Many legacy systems were being decommissioned and, as you can imagine, it required numerous processes to be re written. Despite requests from the project working group, the decision was made by management not to hire any Technical Writers. Why? Firstly, they ‘cost money’; secondly, ‘… anyone can write instructions…’. As a Change practitioner I had a dependency on the process documents since I had to design training and communication artefacts based on the details available on the detailed process documents.

I managed to convince management to allow me to do some quality checking on the process documents written by system SMEs and Operations SMEs. What I found was:

  • Processes didn’t flow logically. There were instructions where step 3 said Go to Step 9 and Step 9 said Restart the process from Step 3. Obviously, the user would get stuck in a loop they had no idea how to come out of!

  • In some cases, the last step was The matter must be escalated to the appropriate system team. But the contact details weren’t provided on the document nor was it made clear which particular job role would be responsible for escalating the matter or how would they escalate it, i.e. via an email or via a system or an online form.

  • In most cases, the principles were mixed with procedures, i.e. the neither the principles written made any sense, nor did the procedures give a user the feeling that they would be able to do what they were required to do.

  • Many of those SMEs didn’t know how to write grammatically correct English to such an extent that some didn’t even know when to use an apostrophe, e.g. some wrote Customer’s must provide ID when requested.

  • The same process used both the terms customers and clients which could lead a user of the document to ask what’s the difference between the two and why are there two terms not one?

  • There were sentences like Contact the customer by calling them on their mobile.

Now let me stop here for a few seconds. If I keep mentioning the challenges that might become a mini thesis. A small but real story sometimes tells you more than what a long investigative report or thesis won’t tell. The point I am attempting to make is there is, it seems, either a strange reluctance or ignorance that stop many organisations from appreciating the great value that Technical Writers add to the world of operations and project management.

Technical Writers are professionals in their own rights and bring with them a tremendous number of skills.

Technical Writers can take the cue from a process map done by a Business Analyst and create a very detailed process document that narrates many aspects of the process(es), e.g. logical sequence, which role does what, where to seek support. In many cases they even challenge (respectfully, of course) the assumptions of the Business Analysts and help the latter produce better quality artefacts. The Business Analysts create documents at a high level, it is the Technical Writers who create documents at a low level for the mid-level and the frontline users.

A well written document done by a Technical Writer is of tremendous value to the Change Manager on the project, as not only it makes the creation of the training documents and conducting of detailed impact analysis easier but also improves the adoption of the new / amended processes by the end users; it also gives the end users a sense of What’s In IT for Me (WIIFM).

A Technical Writer’s knowledge and documentation skills are a great support for a Communication Manager too; when writing communication artefacts, the latter can leverage the gist from the documents done by a Technical Writer.

Technical Writers understand technology and testing activities, e.g. system integration testing (SIT), user acceptance testing(UAT) very well; they often actively participate in SIT or UAT or access systems such as HP ALM or any repository where professional Testers store test results using screenshots to utilise the findings in writing end user documents. Technical Writers respectfully challenge Testers and help fill the gaps in many testing activities which add great value to end users. Sadly though, in most cases Technical Writers do not get any recognition for it.

Technical Writers possess sound project management skills. They often work on multiple processes and documents at the same time. Not only, they project manage their pieces of documents, they coordinate sign off process, set and manage the expectations of stakeholders.

Technical Writers come from diversified backgrounds: arts, communication, psychology, history, engineering. It is important that they get the recognition for the great work they do. By the way, I am not suggesting that all organisations treat them the same way. Indeed, there are some organisations who hugely utilise the skills and services of Technical Writers. Those organisations that fail to appreciate Technical Writers do not even realise that an erroneous judgment of not utilising these great professionals down the track causes slow or unsuccessful adoption of a new process or processes, generates higher number of errors, take longer processing time because of having no clarity, ultimately costs more in money, and most importantly, does disservice to their customers.


bottom of page