I’ve been a software developer for years. I know the process, I know the beginnings, middles, and ends of software projects, and I know this: “when it’s done” is not a good recipe for making money in the software industry.

I believe the same adage applies to writing. The “when it’s done” philosophy just doesn’t work. There are countless stories of young writers working on their book for years, tinkering with it until it’s “perfect”. I always wonder what they could have accomplished if, instead, they’d stopped tinkering and started another book.

The software companies I’ve worked for that prosper all do one thing. They have schedules, and they stick to them. They estimate how long a project will take them, and they decide on milestone dates that allow them to build the project they want to build. They have a process that they follow.

I think those same ideas can be applied to writing books. There will be differences if you self-publish vs going the traditional route, but those differences are only in the implementation. The key is still to come up with a process and to stick to it.

When developing a process, think about the all the steps that need to get done before the project is complete. Yours may end up being different than mine, but here’s the essential process I’ve worked out for me.

1. Write the first draft.
2. Sit on it for a month
3. Read it carefully and make sure everything I wanted to say is there
4. Fix any issues I discovered while reading
5. Send it to a couple readers
6. Fix any errors they find
7. Send it (or publish it)

You may notice that I don’t count outlining and other project development in the process. That stuff is generally done before I count the project as “started”. It’s difficult to set up a deadline if you don’t know all the work involved, and those things are key elements of determining the amount of work involved. (Note: You should try setting a deadline for your development work, too, especially the outlining part if you outline. Otherwise, the development work can turn into a never ending project on it’s own.)

Another person’s process might look like this:

1. Write the first draft
2. Have a reader read it
3. Fix the errors
4. Send it (or publish it)

Another writer might specify several rounds of revisions and drafts. It really doesn’t matter.

Now that you have your process spelled out, assign workable deadlines to each part. Only you know what your schedule is like, so I can’t do it for you, but here is a general approach.

For the first part, you need to determine how fast you write, if you don’t already know. Spend a couple days writing a short story. See how many words per hour you write. Some people write 750 words an hour, others write 1500, others write 250. It doesn’t matter, you just need to know.

You probably have a rough idea how long your project will be, or should be, or what you want it to be. The more you write, the better you’ll become at knowing the length before you start, within a certain percentage. Take that number and divide it by your word per hour rate. For illustration, we’ll use 90,000 words (a typical novel length) and 750 words per hour. It comes out to 120 hours of writing. Add fifty percent to the number, which brings us to 180 hours. That’s the number of hours to use for determining how long you should schedule for your first draft.

Why did I add fifty percent? Basically, crap happens. You get sick, your dog dies, your computer takes a dump. You have to give yourself room to maneuver. In the software industry, the general rule of thumb is to double your initial estimate. There are always unknowns. Give yourself the time to deal with them.

Alternatively, if you write on a regular basis, and you know your typical output per day, say, 1000 words each day you spend writing, you can divide the project word count by that number, and that’s how many actual days you’d have to spend writing. If you don’t write on weekends, of course, you adjust for those. And don’t forget to add fifty percent. Using the example from above, you would schedule 135 writing days.

Now that you know how many hours you need to spend on the draft, figure out how many hours a day you can work on it, and which days you can work on it, and do the math. Figure out where that end date is. Mark it on your calendar. Commit to finishing the draft by that date.

For reader steps, allow them time to read it, especially if they’re doing it for free, but specify a time frame. A month should generally be long enough, though sometimes it isn’t. It’s better to estimate long here, and tell your reader a shorter time that you’d like to have it finished. If they haven’t finished by the end of the time you gave, you have to figure out what you want to do. Either push your other deadlines out, or find a new reader, or both.

For doing revisions, my current policy, because I haven’t done many of them, is to give myself a quarter of the hours that I allocated to my original draft. I’m only fixing things. Again, figure out how many hours you have in your day to do the work, and mark the end date on the calendar. Do not allow yourself to tinker endlessly beyond the end date. Once you hit the deadline, call it done.

All this will add up to a “ship date”. A date on your calendar that you will call it done and just ship it out, either to publishers, agents, or all the ebook distributors.

The key is to be ruthless with those dates. Hitting dates is the difference between a book that gets done, and one that never sees the light of day. Reward yourself for hitting the dates. Give yourself bonuses for completing them early.

When you miss a date, you should immediately write up a small document that examines what went wrong. Did you underestimate the time required for that step? Did you underestimate the size of the project? Were your estimates of time available incorrect? Why did the estimation errors occur?

I’d like to tell you that it’s fine to miss a date here and there, but it’s not. Not if you want to be productive. Not if you want to publish, and publish a lot. Missing dates can become a habit, and it’s a habit that can set you back months or years from achieving your goals.

I know, many of you may be reading this and thinking, “What the hell? I’m an artist! I can’t be constrained by deadlines!” If you’re one of these people, and you’re still reading, I thank you for not giving up on me yet. The process I’m suggesting is completely customizable by you, the artist. You set your own boundaries, whatever they may be. Setting boundaries is how a piece of work gets finished. If you want to give yourself three years to finish a book, by all means, give yourself three years. If working on your book is just a hobby that gives you pleasure, then don’t listen to me.

A schedule is a tool for getting stuff done, nothing more. I have a lot of books I want to write, and I’m sure, by the time I’m done writing them, I’ll have a lot more. I don’t want one of those books to eat up the rest of them, and this is how I’m keeping that from happening.

This post from Kristine Kathryn Rusch last night only adds fuel to my indie fire. Then, when you partner it with this post from Dean Wesley Smith, I can’t see how going through the effort, as a new writer, of the submission grind is ever worth it. Read them both. Weep for the world that was, then glory in the world that has replaced it.