Business of Editing: The Logistics of Large Projects

As I wrote in my previous post, Business of Editing: Taking On Too Much, I have been hired to help edit a portion of a very large project. My portion runs to 5,000 manuscript pages, which have to be edited within 6 weeks.

After having written about the ethical issues of having undertaken a project that was bigger than the original editors could handle, I thought it would be worthwhile to discuss some of the logistical problems of massive projects. Let’s begin at the beginning: This project, before editing of any chapters, ran approximately 8,000 manuscript pages. (I use approximately deliberately as this was the in-house editor’s estimate; I only know with certainty the page count for the chapters I have actually received.)

Projects of that size are the types of project that I often receive and over the years, I have developed a system for working with such massive amounts of manuscript. In fact, it was because of my receiving projects of that size that I developed EditTools. As you can imagine, with such projects consistency becomes a problem, and the stylesheet seems to grow on its own.

The first logistical problem I address is that of editors: How many editors will be needed to edit the manuscript within the time allotted by the schedule? I built my business, Freelance Editorial Services, around the idea that a team of editors can do better financially than a solo editor. Although this notion has been disputed many times over the years, I still believe it to be true, based on discussions that I have with solo colleagues. It is this team concept that enables me to undertake such large projects with confidence, knowing that I will have a sufficient number of well-qualified editors to do the work.

The second logistical problem I address is the online stylesheet and giving access to it to the editors who will be working on the project. I discussed my online stylesheet in Working Effectively Online V — Stylesheets. When several editors work collaboratively on a project, this online stylesheet enables all of the editors to see what decisions have been made, and to conform their decisions with the decisions that have been made by coeditors. Consequently, if an editor makes new editorial decision (i.e., it has not been previously decided by an editor and inserted on the stylesheet) to use distension rather than distention, or to use coworker rather than co-worker, all of the other editors can immediately see that decision — within seconds of its being entered into the stylesheet — and can conform their editing to that decision or dispute it. It also means that errors can be caught and corrected. For example, if an editor enters adriamycin, another editor can correct it to Adriamycin (it is a brand name, not a generic drug) and immediately notify all editors of the original error and correction.

In addition, my client also has access to the stylesheet. The client can view and print it, but not modify it. This serves two purposes: (a) the client can provide proofreaders with up-to-the-minute copies of the stylesheet and (b) the client can look at our editorial decisions and decide that he would prefer, for example, distention rather than distension, notify an editor of the preference, and the editor can then make the change and notify all of the coeditors, who can then make any necessary corrections in chapters not already submitted to the client.

The third logistical problem I address is the creation of a starter NSW (Never Spell Word) file for the project. The Never Spell Word module of EditTools is where known client preferences are stored. For example, if I know that the client prefers distention to distension, I enter into the NSW file the information to change instances of distension to distention. Also into this file goes editorial decisions, such as marking DNA as an acronym that does not ever need to be spelled out but that the acronym US (for ultrasound) should always be spelled out as ultrasound. The NSW file also serves to remind editors of other editorial-decision–related information. I provide each editor with a starter NSW file and each editor will add to their NSW file as they edit.

The NSW macro is run before beginning editing a chapter. Its purpose is to promote consistency across chapters and to make it easier for an editor to visually see editorial decisions that have been made. The NSW macro includes several components. For example, my basic NSW for medical editing also includes a dataset for drugs and organisms. Its use helps speed editing by providing visual clues, such as an indication that a drug name is correct even though the spell checker is flagging it as erroneous — it becomes one less thing that I need to verify.

The fourth logistical problem I tackle is references. These projects often have lots of references. One chapter of the project that I just received, for example, runs 305 manuscript pages, of which there are 61 pages of references — a total of 652 references (most of the chapters have more than 300 references). Dealing with references can be time-consuming. My approach is to separate the references from the main chapter, putting them in their own file. This serves four purposes: (a) Microsoft, in its wisdom, has determined that if spell check determines there are more than some number of errors in a document, it will display a message that there are too many errors for Word to display and turns off spell check. Although spell check is not perfect, it is a tool that I do use when editing. I would prefer it to flag a correctly spelled word as misspelled, giving me an alert, than my possibly missing something. Spell check is a tool, not a solution. (However, it does help that EditTools helps me create custom dictionaries so that correct words that are currently flagged as errors by spell check can easily be added to a custom dictionary and not flagged in the future.) By moving the references to their own file, I eliminate this problem of Word turning off spell check for too many errors.

(b) It provides me with an opportunity to run my Journals macro. Every time I come across a new variation of a spelling of a journal name, I add it to one of my journal datasets. My PubMed (medical) journals dataset currently has more 14,675 entries. With the references in a separate file, I can run that dataset against the reference list and have my macro correct those journal names that are incorrect (assuming the information is in my dataset) and mark as correct those that are correct. What this means is that rather than having to check journal names for 652 references in a chapter, I have to do so for at most a handful. It also means that I can concentrate on the other reference errors, if any, such as missing author names. Instead of spending several hours on the references alone, I can edit the references in a much shorter amount of time. (It took 26 minutes for the Journals macro to check the 652 references against the 14,675 entries in the dataset.)

(c) The third purpose is that separating the references from the main text lets me run the Page Number Format macro. In less than a minute, I had changed the page numbers in the 652 references from 1607-10 to 1607-1610 format. How long would it take to do this manually? Having the references in their own file means I do not have to worry about the macro making unwanted changes in the main text, especially as this macro runs without tracking.

(d) The fourth purpose separating the references from the main body of the chapter serves is that it lets me run my Wildcard Find & Replace macro just on the references. There is no chance that I will use the macro and make unwanted changes to the main text. WFR is efficient because it lets me create a macro that works, such as one to closeup the year-volume-pages cite, and save it for future reuse. WFR even lets me combine several of the macros into a single script (that also can be saved for repeat use) so that the macros run sequentially in my designated order. As an example: I have created macros to change author names from the format Author, F. H., to Author FH,. If you have to do this manually for several thousand author names, you begin to appreciate the power and usefulness of WFR and how much time it can save. (I also will use WFR on the main text when appropriate. What I avoid by separating out the references is the possibility of something happening to either the main text or the references that shouldn’t.)

The above steps are among those I take that make handling of large projects easier and more profitable. There are additional things that I do for each chapter, but the point is that by dealing with manuscript in a logical way, projects become manageable. In addition, by using the right tools, editing is more accurate, consistent, and faster, which leads to a happy client, more work, and increased profitability.

Do you have any thoughts on how to handle large amounts of manuscript? Do you take any special steps for preparing a manuscript for editing or while editing?