Technical Writer

The Dummies series of books are a writer’s dream.  Clean, well written, with personality and an easy read.  Perfect as both a reference and as a learning tool.

I flicked through Digital Photography for Dummies over the weekend.  Very nice.  My business partner, Calder, also recommends QuickBooks for Dummies. Yet the only Dummies book I ever read was C++ for Dummies, and I confess I didn’t read much.

My C++ was rusty.  I had spent two years coding C++ at university but hadn’t touched it since, and then I had to document code written in that language.  I bought C++ for Dummies as a memory jog.

I never finished the book.  I couldn’t understand it.

The author constantly referred back to how things worked in C, which I had never used. It totally lost me as a reader and I didn’t bother to read more than a couple of chapters. I will never know how good the book was, or wasn’t.

Comparing new programs to old ones works for a cutover period, when the bulk of people using the new program are converts from the old, but it becomes really frustrating after that, even to these converted users.

Microsoft has just released (or is about to release) Office 2007, and I imagine this will bring on a rush of cross-over books, which is fine, but for how long are they needed, and what do you do with them after they are finished?

A lot of cross-over information will be posted on the word wide web and on intranets.  A lot of it will stay there long after its use-by date.  They gradually disappear, but even now the occasional Google search brings up instructions on how to do something in Office 2003 compared to doing the same thing in Office 95.

A lot of the cross-over material gets forgotten.  I recently looked at some old “Introduction to SharePoint” CBTs I wrote for our implementation of SharePoint as an intranet, and realised that some of these modules still referred to ‘how we will do things in our new system’, even though we have been doing it this way for two years now, and over 50% of our current staff had not even been working at the company when we implemented it.

When do you know it’s time for the cross-over material to go and how do you keep track of what has to be changed?

Maybe there’s another way to do it.

Microsoft have introduced the interactive: Word 2003 to Word 2007 Command Reference Guide which allows you to choose a menu option in Word 2003 and then shows you how to do the same thing in 2007.

I really like this, because I am not good at remembering the names of commands. 

If I want to change a style I know which menu I have to go to, and which option to click on when I get to that menu, but if you asked me how do do it I wouldn’t be able to say, “Click on the Format menu, and then choose Styles and Formatting.”  I would have to check it and do it.

Using a tool like the Word 2003 to Word 2007 Command Reference Guide I can re-write procedures totally in Word 2007, but for those people who already know what to do in Word 2003, I can just provide a link and say, “Go to it.”

Later on, when everyone is familiar with Office 2007, I can remove the link.

It’s much tidier, and a lot easier to manage.

Back in the days before international outsourcing, before the dot com bust, I worked as a contract writer for a government department (now sold off as a private enterprise).

We were a fairly big team, most of us long-term contractors contracting for one of the big consulting companies who ran the IT department for this particular utility.

One of the consultants was in charge of the writing team.

We used to call them ‘droids’, as in androids, because as soon as one left, another one exactly like them took their place.

You know the types—just out of university, fresh from the company indoctrination, and they’re dumped in the middle of a project and told to run it. 

These young things were bright—the cream of their university year, keen and ready to work hard.  But they had absolutely no experience running projects and every single one of them made the same basic mistakes. Every time.

We contractors could say, “But we tried that, and it didn’t work. In fact, it hasn’t worked the last five times we tried it.”

Sometimes we felt we were right in the middle of a Dilbert cartoon.

I’m sure the consulting company used the Documentation department to train their graduates. I’m sure they provided mentoring, but sometimes we wondered. Sometimes it seemed more sink or swim than any other training.

It almost seemed as if the project managers had to make these mistakes to learn from them.

Just when they were starting to get good at their job, the consulting company moved them on to a more senior position, and we ended up with another droid.

At a recent function the speaker, Rob Thomsett*, mentioned that he hated overheads and refused to use them. He then proceeded to give an entertaining, one-hour speech with his only prop the microphone he used so we could all hear him.

The day after Rob’s talk I went to a meeting on standards.

This was supposed to be an informal initial discussion, but the co-ordinator used overheads to denote major topics. While there was nothing wrong with his use of them, the overheads made the whole meeting a lot more formal. He could have used notes instead, and introduced the topics that way, which was more in the planned spirit of the meeting.

At the time I was running a series of three-hour workshops. At these workshops I used overheads interspersed with practical examples.

The overheads provided an introduction to each topic, and some memory joggers for when the participant went back to their desk. However, this meant we were constantly switching between the overheads and the system I demonstrated.

The next workshop after Rob’s talk I decided to do away with the overheads altogether—except for a few introductory ones at the start and some closing ones at the end.

It worked well, and I use this technique all the time now for these workshops.

“So what,” you might say. “Everyone knows most people overuse overheads.”

While we all want to design perfect materials, the fact is that we don’t. We work to deadlines and don’t always have the luxury of creating perfect material. If we’re a lone writer we don’t have anyone to bounce ideas off, to suggest there may be a better way.

It’s easy to slip into bad habits without realising.

Sometimes it takes a chance remark, like Rob Thomsett’s, to make us reassess how we do things.

That’s always good.

---

* Rob is a great speaker, and knows a lot about project management. I highly recommend that if you ever get the chance to hear him speak, take it. His Rough Rules of Management include “You know a project is failing when you can’t stop it”, which contains some truths that most of us would nod our head over.