There are several good books that cover project planning. I like Steve McConnell's Code Complete: A Practical Handbook of Software Construction. Another practical piece of advice is to study your prior projects, and start with a broad outline based on those, with pieces to fill in for the new projects.

But that ducks the question of why you believe that project planning should be faster/easier than you experience it now. What you may be experiencing is the tension between a belief that planning should be easy, and the reality that project planning can often be, well, hard.

To do a project plan for anything substantial, you effectively need to "do" the project in your head (or in a group of heads) or on paper to make sure that you understand the objectives and requirements. Then you break the imagined work down into pieces. Then estimates have to be tacked onto each of the pieces (hopefully by the people who'll actually be doing the work). Then the other activities that need to happen to achieve the desired outcome need to be factored in. Writing time. QA/testing time. Etc., etc., etc. This can be hard work.

For a sizeable project, planning can take a lot of time, particularly when the requirements are vague or incomplete (or when they keep changing), or when you're attacking some new problem that you haven't solved before, and you end up needing to build a prototype so that you can understand what you'll need to do to build the real artifact.

And to add to this, you might be dealing with the form of Management that truly believes that accurate schedules should spring full-born from your brow after a mere weekend's consideration. If they are able to indoctrinate you through forced beatings into this childish fantasy of a belief, than you are doomed to suffer until the believe is exorcised.

So, you say that you have problems with schedule and that they shouldn't take as long as they do. What problems are you running into? And what have you seen or heard or read that leads you be believe that schedules should take you less time than they're taking you now?

Well. The problems that I'm running into I think have something to do with the way I organize or actually because I <bold>don't</bold> organize.
I really appreciate the simple advice you gave me about looking at my prior projects. I think that may help me improve greatly. (why didn't that come to mind)
I can think of a few things off the top of my head that I could do along the way to improve my focus when working on something.

Thanks again for all of your help and advice.

A very good book pack on this topic is ISBN 0735605971, especially Software Project Survival Guide by Steve McConnell (again). The latter one has a lot of templates and checklists, suitable mostly for larger projects.

A nice, if somewhat pedantic book on planning your personal work is Introduction to the Personal Software Process (ISBN 0201548097). It contains a lot of advice of how to monitor your own work process, including a lot of forms to record more or less relevant information. While the whole pack might be more of use to really bureaucratic types, the part on time recording and the part on recording defects in your programs are definitively worth reading.

Third, I want to follow up the recommendation by lachoy on the Pragmatic Programmer book. If you want to enjoy the wisdom of this book on your command line (similar to the Unix fortune command), try this script.

And, last but not least, never forget that planning has something to do with thinking. Planning is not following plans blindly. Always ask: What do you really want to achieve? Everything else follows from that. Some tools for thinking (funny, eh) are taught in the aptly-titled The Thinkers Toolkit (ISBN 0812928083), which is really a cool little booklet with a good value for its price.

In fact, planning is like programming at a higher level - but with a new, ever changing runtime environment each time, and without debugger.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

Edit: chipmunk 2001-03-20

Thanks a lot for the tip script.
I will definitely be checking out Pragmatic Programmer book
(despite the fact that the author collaborated on Programming Ruby: The Pragmatic Programmer's Guide)

Actually both books have the same two authors.

But why would their having collaborated on a Ruby book make you turn your nose up at a general programming book? This sounds more like bigotry to me than anything else. The best programmers in any language tend to know several - and like multiple ones. It is much easier to notice that a language over there has a nice feature that works well and borrow it than it is to come up with original ideas. Larry Wall knows this well, which is why Perl derives from so many sources. I hope he continues to do so.

Also see Why I Hate Advocacy by Dominus. And think carefully about what he has to say.

Don't knock a new tool until you have tried it. And just because someone likes one tool that you don't is no reason to never deal with them again.

Other useful books/info: The Pragmatic Programmer has very useful advice regarding planning and estimating. And planning is a central part of the whole extreme programming philosophy (don't call it a methodology!).

Personally, I tend to do sufficient planning until I start making broad generalizations, then code up to that "point", go back to planning, then iterate iterate iterate. The time for this initial period depends on the scope of the project -- it could be 15 minutes or it could be a week or two.

Chris
M-x auto-bs-mode