Terrible things that can go wrong in your book project (and what to do about them)

The most demoralizing problems in a nonfiction book happen near the end of the project. A setback at the point when you were hoping to be moving the book to its completion might force you to redo a lot of the work you already did.

Here’s a list of what might go wrong, how to prevent it, and how to recover from it.

Lost files

Hard drives crash. People’s laptops get stolen. Files get corrupted or overwritten. At some point, you may find your latest, nearly-complete version of the text is no longer accessible to you.

How to prevent it: Save versions under other names along the way, so you can always go back to the previous version. And back them up. If you store your files in a cloud directory system like Google Drive, you’ll likely have both local and remote copies of files, an automatic sort of backup. But be paranoid and make other backups, too, in case your cloud-based system fails or it locks you out (both of which have been known to happen). Email a copy of the manuscript to another email address. These efforts are annoying ways to eat up a little time until you find yourself desperately in need of a backup, at which point you’ll thank your previous self.

How to recover: If you’ve lost all versions of your manuscript — which I hope never happens — you can always go look at the “Sent” folder of your email and see if you’ve emailed a version to a reviewer at some point in the past. Or contact that reviewer and sheepishly ask for a copy of what you sent them.

Version control chaos

Version control discipline is essential when working with others, like ghostwriters, coauthors, editors, or reviewers. If you and your collaborators are both attempting to make edits at the same time, you’ll end up with multiple versions of the document that need to be resolved. (And yes, I know tools like Google Docs and Microsoft Office 365 allow multiple people to work on a file at once, but it’s still messy if the primary writer is writing while someone else is editing.)

How to prevent it: The basic principle is, never have more than one person working on a file at the same time. Work on one chapter at a time; that way, you can be writing Chapter 3 while your coauthor or editor is reviewing what you wrote in Chapter 2. At any given moment, a chapter should either be in a writing process or being reviewed, not both.

How to recover: If you use Microsoft Word, there’s an excellent tool for comparing and merging versions. It’s still a pain in the butt, but it’s better than nothing.

“Just one more reviewer”

Somehow, at the end of book projects, there’s always another reviewer materializing. It could be the author’s spouse or boss, but seems like there’s always somebody with veto power looming over the project, ready to mess it up at the last moment.

How to prevent it: You can’t avoid those powerful reviewers. What you can do is integrate them into a normal review process. Figure out early in the process who those “veto” reviewers are and loop them into the process, rather than leave them looming with the possibility to blow things up later. As soon as there is a draft to review — even if it’s not complete, or not polished — get them to take a look at it and incorporate their feedback. Here’s another trick: get the draft printed out and wire-bound at a place like Kinko’s or Staples, and pass that to the reviewer. A printed document communicates “This is almost done, so don’t crap all over it,” — even if it isn’t nearly done at all.

How to recover: Write the best book you can, carefully structured and sourced. If the book is compellingly written, a late reviewer isn’t likely to have a big problem with it. A skillful writer can figure out how to deftly change or delete a few words to address the reviewer’s criticism without blowing up the whole document.

Permission withdrawn

Your book is made of stories, at least in part. Those stories are based on interviews. And your interview subjects have usually given implicit permission for you to use their stories. What happens if they change their minds?

How to prevent it: Start each interview with “This is an on-the-record interview. I’ll send the part of the book about you to you later so you can verify that the facts are correct.” Also include this text in your email confirming the interview. This ensures that, at least legally speaking, you can use the the interview. In general, so long as your interview subjects are the heroes of your case study stories, they’ll be happy with the results. If they feel something you have written is inaccurate, you can usually fix it without destroying the story.

How to recover: Even if you’ve told the interview subject that the interview is on the record, they may object. For example, in one case, a large company we interviewed (okay, it was FedEx) had lawyers who insisted we mark their name with the trademark symbol each time we used it, which would have made the manuscript look stupid. You can often negotiate things like this (in the case of FedEx, we agreed to mark their trademark as belonging to them on the copyright page of the manuscript rather than in the running text). Worst case, you can tell the story with names of the company and the protagonist replaced by pseudonyms. It’s unlikely anyone can object to a story that doesn’t mention them or their company by name.

Title remorse

It’s best to settle on a title at the start of the project, to avoid entering “title hell.” But what happens if you change your mind halfway through?

How to avoid it: So long as you don’t have a satisfactory title, that fact should be nagging at the back of your mind. Don’t ignore it. Resolve it as soon as you can, hopefully at a point where the title can be effectively worked into the manuscript.

How to recover: At some point — even at the end — your book has to have a title. If you change the title near the end of the process, try to do it in a way that still connects to a theme that’s used throughout the book. (The scene in “American Fiction” where the author changes the title at the last minute was the most unrealistic part of a move that was full of things that would never really happen in publishing.)

The graphics quagmire

One thing is more likely to mess up a book process at the end than any other: graphics. Everything from design to file type to formatting can cause problems with illustrations.

How to avoid it: Hire a professional designer to work with. Package up all the graphics in one neat package, with placeholders to show where they go in the manuscript. Keep control of the source files for all graphics, so you can make modifications easily.

How to recover: If a graphic is causing a problem, rethink it. Does it have to be this big? Is there a way to show it as a table? (Tables are far easier to format.) Could you scrap it altogether, or put in online where people can see it in a better form? Some graphics just aren’t worth the effort.

Discipline and planning will always pay off

The more chaotic your process, the more likely you’ll have a painful disaster at the end of it.

The disciplined author plans chapters, prepares interviews, manages reviewers, and wrangles versions in an orderly way. Then if something goes wrong, it’s far easier to fix.

And write in a modular way. Keep your case studies, argumentation, and recommendations in separate parts of the chapter. It’s a lot easier to fix problems if you can keep them contained within a modular manuscript element.

Stuff goes wrong. Smart authors can recover. Unless you enjoy reworking work you already did, take heed.

There really needs be a book about all this stuff.