|
By Mike Gunderloy One of the big jobs in writing a book is planning and scheduling the whole thing. I can't tell you how to plan your own books, but I can tell you what works for me. In my book-writing life, there are two essential tools: the outline and the schedule worksheet. I'll discuss them in turn. The outline is, of course, a Word document that outlines the entire book. In most cases, you'll actually need to finish this and get it approved by the publisher before you get a book contract. Depending on the size of the book and the complexity of the subject matter, I normally carry my outline to either B or C heads. (An "A head" is the first level of subdivision with in a chapter; depending on the book you might go as deep as F or G heads, though that's mighty rare). I usually just use Word's outline view and let it automatically number things for me. The outline should do three things for you: settle the scope, depth, and organization of the material in the book. If it doesn't do all three of these things, you're not finished outlining. The scope of the book determines which topics you'll cover. If you're tackling Microsoft SQL Server, for example, will you include a chapter on DBLib? On using client applications with SQL Server? On installing the software? There are many choices to be made in determining just what's going to go between the covers. Typically you'll settle scope in conjunction with the developmental editor ("dev ed", the person whose job it is to nurse proposals along until they become contracts) at your publisher. They'll consider what they think can be marketed and the proposed page count of the book in helping you make these decisions. Often, coming up with the perfect title for your new book will go a long way towards settling the scope. The depth of the book determines the level of detail that you'll apply to each topic. If you're writing about some VB .NET code, do you stop and explain each class and namespace that you use? Do you include a primer on the VB .NET language? The best way to set the depth is to have a good idea who your target reader is. Also, page count issues will come into play here as well; once you know the pagecount and the scope, the depth is fixed. The organization of the book, of course, determines the order that you present the material in. There's always some kind of natural progression, if only you can find it. Typically a programming book will include introductory material first followed by more advanced topics, but even that isn't set in stone. If your book covers several areas, it might make sense to group these into parts (A "part" is a group of chapters) and to go from introductory to advanced in each part. After the outline is finished and approved by the publisher, I turn revision marks on and keep it updated. It's not unusual to move a section from one chapter to another, or to add or delete sections, as I work on the book. The revision marks let me see what changes I've made, and help me tell whether I'm at a point where I need to check with the editorial team to make sure they agree I'm still on the right track. Each time I start a new chapter, I open a Word document based on the publisher's supplied template and paste in the appropriate chunk of the outline. Then I'm ready to start filling in the details. The other important document for me is the schedule. This is an Excel worksheet that I keep open pretty much every day as I'm writing, and it's my main tool for staying on schedule. (If you don't stay on schedule, you'll be sorry; trying to churn out half the book in the last two weeks of the contract won't work). I usually end up with these columns:
If the book is a collaboration, I'll add some additional columns showing who the lead author is on each chapter, and the dates at which drafts are swapped between authors. In addition to each chapter, the worksheet also has rows for the front matter (introduction, acknowledgements, dedication) and any appendixes. The dates are the key points in the life cycle of each chapter. Typically, the process goes like this: you write the chapter and send it in. The chapter gets reviewed by both a copy editor (who knows the English language) and a technical editor (who knows the topic). They put comments, corrections, and questions in, and the result comes back to you: that's the author review, or A/R, version of the chapter. You read through the A/R chapter, add your own remarks, answer any queries, and send it back to the publisher. They clean it up and turn it into something that looks like the actual chapter; that's the galley proof (galleys used to be on paper, but now everyone I work with is using PDF files instead). You make a list of any remaining errors (hopefully very few, because they're expensive to fix at this point) and send it back. Once you've gotten to this point for every chapter, the book is done. When I start my schedule sheet, I fill in the chapter numbers and titles, estimated page counts (actually pretty important, because the book's budget is based on the page count in the contract; you can't deviate far from this without repercussions), and the date that I plan to submit each chapter to the publisher. Your contract certainly specify a date when the manuscript must be complete, and it may specify milestone dates as well (when half or a third or a fourth of the manuscript is due). Those dates will help you fill in the dates you plan for each chapter. I normally figure on one chapter per week as my maximum output of book-quality material, and try to get each chapter on the same day of the week. Note that the order that you write the chapters does not have to be the same order that the chapters will appear in the book. If the book starts with a broad overview chapter, I almost always write that chapter last; that way I can ensure that it will actually correspond to the rest of the book. You may have other reasons for writing chapters out of order. For example, it can be worthwhile to start with a chapter out of the center of the book if it's material that you know very well. That can help you build up some "hey, this isn't so hard" momentum. One last thing I put on my schedule worksheet is a list of the advance payments and what they're tied to. That's the surest way to make sure that I send a polite note to the editor ("Here's chapter 6, which brings me to 25% complete. I'll look forward to the advance check when you've had a chance to look it over.") when I hit each payment milestone. After you've set up your schedule, do your best to stick to it relentlessly. Acts of war and major natural disasters might be sufficient cause to slip the schedule, but almost nothing else is (especially in the eyes of the publisher). Your contract probably has language that lets them cancel the book and demand the money back if you screw up the schedule too badly. Realistically, most book projects can accomodate a few weeks or a month of slippage along the way, but if you do need to slip, you need to let your editor know as soon as you can. Remember, they're scheduling resources on their side of the fence to do things like edit, create art, and lay out the book, so your being late affects a lot of people. Best advice: don't slip. Being on time and on page count will make your editors love you, which in turn increases your chance of getting another book contract. Mike Gunderloy is the lead developer for Larkware and author of numerous books and articles on programming topics. |