Click the link below for a perfect example of why it’s important to keep your documents up to date.
http://www.ajc.com/business/delta-apologizes-for-bumping-827880.html
Category: Writing
Categories
Paying Attention to the Details
As technical writers, we notice a lot of things that other people do not. I tend to notice too much because I’m a little too detail-oriented for my own good. But this can help improve whatever product, service, etc. I am documenting.
At Shoap Technical Services, we take pride in our ability to offer our clients fixed-priced bids for technical documentation and training. We feel that this is an advantage to our clients because everyone likes to know how much a project is going to cost before they start. And we feel confidant that we can correctly estimate a project because 1) we’ve done so many technical writing and training projects over the past 25 years and 2) we’ve learned how to break down a project into small enough parts so we can assign numbers (time) to each part to determine a total cost. What we like to say is, “If we can put our arms around the project, we can successfully bid it.” While we have, at times, missed our estimates and had to finish a project at a loss, most of the time we’re pretty accurate. That makes our clients happy because they know from the outset what they’re going to have to pay and it allows us to make enough money to stay in business.
As a student of writing for well over 40 years, I’ve learned one thing: you can’t write about what you don’t understand. This is true whether the topic is Shakespeare’s contemporaries (my doctoral thesis topic), what you did during your summer vacation (a topic I never assigned when I taught Comp 101), or the attributes of an SQL database (which my company has recently done). Or perhaps a more accurate statement might be, you can write about something you don’t understand but no one will understand what you’re saying.
Categories
Use Your Words!
Precise word choices are one of the hallmarks of a great technical writer. Even if you don’t have much difficulty picking the right words and phrases when expressing your own thoughts, I’m sure you’ve encountered a situation where you ran into problems interpreting a client or SME’s writing/requests/emails. Here’s some links to some of the handy reference tools that I sometimes use to help me interpret a client’s requests or find the perfect word or phrase. Hopefully these will make a difference in your writing in 2011!
Aberdeen Group completed a study earlier this year that indicates when technical communications are approached strategically, companies provide significant customer-facing value. – David Houlihan, Senior Research with Aberdeen’s Product Innovation and Engineering Practice.
Christmas, 2009:
The penguin wrapping paper is shredded from an oblong, rectangular package, carefully branded by a stark white apple on black monochrome — The Apple iPod ® Nano. The product is reverently lifted from the case along with the ear buds and sleek quick start guide, leaving the thick, intimidating, and unhelpful paper manual in the bottom — it might as well have been packing peanuts. Why do manufacturers bother with the archaic manual documentation which wastes paper, takes up unneeded space, and adds weight to the shipping fee? The product is blithely toyed with, prodded, poked, and explored without so much as a cursory glance to the woe begotten manual in the box, the user happily glancing through the quick start guide if they come upon any snags in the process of operating their new system. The manual is never read, collects dust, and slowly sinks into oblivion. Let’s explore why the manual falls to such a fate.
… we have come to value … working software over comprehensive documentation…
We don’t do a lot of work with practitioners of agile methodologies. I think that’s partly because there’s some built-in hostility towards documentation in the values of agile development. Of course, while the Agile Manifesto is referring mostly to documentation for the front end of the cycle (i.e., the giant FRS), that hostility ends up spilling over to end-user documentation as well. (I don’t think that was the intention.)
As a technical writer, I feel communicating well is the primary focus of my job. Perhaps this is why I found the following email exchange particularly comical today:
Email from <name deleted to protect the innocent … or not so innocent>:
It is often difficult to know what the priorities are when creating a successful new program. As a project manager for Shoap Technical Services, I have a fair amount of experience initiating new projects. Over the years, I have developed a few key “rules” for every project. While I could just go through my list and explain why I think each rule is important, I think it is easiest to learn through experience, so I have illustrated them through a case study of a recent project.