In our ever more technical world, documentation is still one of the most important aspects. Everyone likes to “feel the weight” of what they accomplished, and documentation is commonly a major part of closure in a project.
The Second Eye
If you have ever had to write a program or a document that was 2000 pages or longer, you will probably get to the point of forgetting what you wrote days, weeks, or months ago. I know I do. That is where a good editor can save the day. Make it a habit of passing along the content in reasonably sized pieces to another soul who dutifully reads every line, checks every drawing for accuracy, and checks syntax and examples. This is a truly wonderful thing.
A second set of eyes will see things that you cannot. Spelling, grammar, syntax, run on sentences, redundancy, too much or too little detail, irrelevant details, your own quirky tidbits that might not be as clear to them as to you, the list is endless ... and the work is absolutely crucial!
Praise Your Editor
Thank them for finding those errors that you were unable to see after looking at the same page for hours. Most modern word processors can handle spelling errors but not if they are technical jargon or corporate jargon.
I like to break my content into smaller, specific pieces if possible, but this does depend on the client requirements. If the programs are small, then the sections can be small and succinct. In some cases, the sections require previous sections to be completed and functioning. Only someone who was totally familiar with the whole picture, the end product, and the inter-relationships of the pieces can provide you with a good set of eyes to review your content with.
Send them praises: Excellent work finding “the the”, “good idea to add that as well”, “you are once again correct, that part is unnecessary”. “good eye, I forgot that topic entirely”…
Editing is an Art
Being an editor requires a great depth and breadth of knowledge on the subject. I would not pass this document on to my teenage daughter; it would be gibberish. She once asked me to “fix” her paragraphs about the Crusades. I expounded on them and thought I was keeping it simple. Alas, I was way too technical. I added about 10 extra words for every two of hers. Then there are many times when I edit her words to be, shall we say, more accurate.
On some recent technical documents, I was doing the developing and passing it on to three evil editors. The first two were masochistic, butchering the youngling without regard for effect, it seemed. They passed it to the third editor, a very technical person, who must have thought I was completely incompetent when he got the butchered remains of my work. It was an interesting few months of trying to figure out their system. And, interestingly enough, that last technical editor was actually very competent. He never missed a detail, was very thorough and fortunately knew his stuff. The other two butchers were trying to fit the content into a web page design rather than have the web page provide the content.
Editing Adds Time
It is highly likely that your editor is not doing this full time for you. Hence, you need to allow for their scheduling requirements within your schedule. Having lots of lag time is always nice. Giving them clearly stated times and dates for delivery of their edits are other important aspects. Everything takes time, and time gets consumed faster the closer the project deadline is.
When I line up an editor, I make it clear there is some flexibility in their timelines at the beginning especially and I try to ensure that deadlines do not force me, or them, to cut corners. Deadlines really are annoying at times! I also make it very clear what the deadlines are and how they can help me meet them, along with general ideas of what I want them to look for, and how they should send change requests or make adjustments.
Give Them Source or Don’t Give Them Source?
This can be a tricky issue. Should you give your editor the source and let them make changes directly to the document? Yes and no.
If you can have tracking of changes, this is always an excellent idea. What if they change your source document without tracking the changes? If you are working with a competent editor to whom you have given this option and in whose inputs you trust, then this is one way to get it done faster. You should, of course, edit their changes for them!
In some cases, as the editor, you may not get the source code, or as the owner of the document, you may not want to give them the source. In some of my recent projects, I would get a PDF of the document. This was fine for simple grammar and syntax errors but became onerous when major changes were required. I was forced to send in “sticky notes” of changes. This is probably the least efficient method for the editor, but it does maintain total control by the owner of the document. There are probably a lot of good and bad reasons for using this method, I just cannot think of any good ones.
Being an editor is important and can be rewarding. Having a bad system for rendering changes will ruin the relationship. A good project management truism is to retain your best support people, and especially a good editor. They make your project that much easier to complete on time.
Copyright © Global Knowledge Training LLC. All rights reserved.
David Egan, RHCE, PMP,