IT hiccups, I've had a few, and usually an IT expert has fixed them for me. Problems have arisen only when the said expert has advised me in writing.
Take a recent letter I received from the technical services department of a well-known telecoms company. The letter included an extremely comprehensive breakdown of the technical issues blighting my firm's telephone system, together with some convoluted instructions on how to resolve the problem. The letter was appallingly written, which means I will be equally clueless about what to do should the problem occur again. More future work for the technical services department in question, then.
Technical jargon and unfathomable abbreviations were the biggest culprits in my particular letter. Then there were the never-ending sentences that I had to keep rereading, intertwined with the odd burst of "text speak".
But let's be fair here. IT professionals are on the receiving end of poor written communication too. Some 80% of employees in the global IS department at one blue chip company claimed that over-long documents and unnecessary jargon reduced their ability to work effectively.
There is no reason why IT expertise should go hand in hand with an instinctive ability to write. And few people go into the field because they love writing. But good writing is a core skill. It reduces complaints and wasted time and it can win new contracts and improve internal processes.
There is no miracle path to crisp and concise writing. But there are a few tried-and-tested techniques that can help to improve your writing skills.
Who are you writing for?
OK, you are an IT expert, but is your reader? The biggest fault with IT professionals is their inability to communicate in clear, "non-techie" English. Avoid technical jargon and gobbledygook when writing for a lay audience. Instead, use plain and simple language and don't overwhelm readers with technical information that they neither want nor understand.
This is easier said than done when you're immersed in technical terms and use them all the time when communicating with your colleagues. So you need to stop and consider your reader's level of knowledge and interest, and tailor your language and the level of detail appropriately. At first, this might take a lot more time, but it will get easier with practice.
What do you want to say?
Think about your main points. What is it crucial for the reader to understand? For technical support response, it might be the long-term solution to the problem. For a proposal, it might be the two or three issues the client is most concerned with (the "win themes").
Make sure these points are immediately clear to the reader and not hidden under layers of analysis and background detail. You can always go on to give supporting arguments and information later in the document.
E-mails should highlight the main points in the first two paragraphs. If you delay those key issues any longer, the reader will lose interest. Reports and proposals should have a one- or two-page executive summary highlighting the main points, for the same reason.
Clarify your thoughts
Consider the main subject areas and issues you need to cover before you start to write. Use each heading to brainstorm all the points related to that subject.
Next, think about the structure and decide what goes where and in what format.
Make sure you outline the situation, problem and solution logically when replying to customer queries or complaints.
Avoid clichés and pompous hype
Clichés and hype do not promote quality customer service. I recently received an e-mail from a technical helpdesk that began, "Thank you for contacting XYZ. We are committed to creating the best customer experience possible. One of the key ways we can demonstrate our commitment to this goal is by quickly and efficiently handling your recent request." The e-mail continued in a similar vein. Unfortunately, in the rush to reply"quickly and efficiently with the help of standard text, the writer also forgot to respond to my original question.
If you want someone to do something, ask or tell them directly. So don't write, "It is essential that customers include the serial number of their device." Instead, write, "Please be sure to tell us the serial number of your device." (And tell them where to find it.)
Punctuation, grammar and spelling
Poor punctuation, grammar and spelling are more common in IT than any other industry or profession. Pay attention to punctuation and sentence structure and always use spellcheck. Sloppiness suggests lack of care and interest.
Short, active sentences in plain English work best
Keep sentences short and stick to one idea only. Don't try to link together lots of ideas in one sentence and hope that a sprinkling of commas will give clarity. They won't.
Conversely, don't use "text speak" for e-mails and reports. It is unprofessional and a real bugbear for many people.
Use active verb constructions as much as possible. "The helpdesk has solved the problem" is a lot better than "The problem has been solved by the helpdesk" because it is shorter and easier to read.
And use plain English. The use of long and redundant words will not make you appear more professional.
Start sentences with the main point
Don't leave the main point of your sentence till the end:
"Owing to staff training and vital maintenance work, the system will be down for two hours this afternoon from 4pm to 6pm."
Give readers the most relevant part of the sentence (the "what") before the supporting information (the "why"):
"The system will be down from 4pm to 6pm this afternoon, owing to staff training and vital maintenance work."
Putting it into practice
"In consideration of the current situation illustrated above and concerns regarding the PRISM system it is proposed that in the first instance PRISM is upgraded to v7.2 with a further review to follow within 2008/2009."
"This and concerns about the Prism system mean it would be best to upgrade to the latest version of the software first. We will then review its performance within the next two years."
Robert Ashton is chief executive of business-writing company Emphasis
This was first published in January 2008