For decades I’ve struggled with scheduling book development projects—especially first editions of first books by new authors. Now I see the reason: many of these projects defy scheduling — and for good reason.
I explored this issue in Are Your Writing Deadlines Meaningless? Recently I found confirmation in a nice piece by Wyatt Jenkins about The Downside of Timelines. His post is about software development. Mine is about book development. Same deal.
What makes timelines so problematic for complex creative projects — such as producing 40,000 to 100,000 compelling words on a timely topic?
The main reason is that such development is not linear. Creative projects are often not a matter of setting a clear vision of the result and taking a straight line to implement it. Instead, developers typically stop mid-project to assess what they’re doing. And they may well conclude that the project needs to be significantly revised or even scrapped.
This is not a mistake. It’s called learning. There are some things that you simply cannot know until you get your hands dirty and start making parts and assembling them. Reality is messy and defies our attempts to beat it into orderly submission.
This is hard to explain to people who like to craft Gantt charts and schedules. I empathize with them. I like rules and order, too. But makers know that the process is full of surprises, detours, land mines, lions, tigers, and bears. People who write books, for example, might discover that they have nothing to say.
As Wyatt Jenkins points out, there are ways to hold creative people accountable other than chaining them to meaningless deadlines. My favorite strategy: take a cue from Getting Things Done by David Allen and commit to take the next action that will move the project forward.
In book development, for example, your next action might be to draft a table of contents or write the overview section of your book proposal. Either document is 2-4 pages—500 to 1,000 words. Such tasks are crucial and still small enough to meaningfully schedule and budget. Best of all, they’ll teach you a lot and bring you substantially closer to a finished manuscript.
P.S. There are exceptions to what I’m saying. For example: you’ve already got a book published and are doing minor or manageable updates for a new edition. Then it makes sense to pull out your Gantt charts and schedules and abide by them. The more predictable a project, the more that tight scheduling makes sense.
P.P.S. I tweeted about Wyatt’s post:
Scheduling a book project? “You can’t schedule substantial complexity” [@wyatt_earp_]
And he replied:
Rephrase: it’s a ton of effort schedule? Additionally, output of “a schedule” is less valuable than output of “a working product.”
Excellent point: the time spent on detailed bids can instead be used to make a minimum viable product.