How can I learn more about project management beyond to-do lists?

http://www.amazon.com/exec/obidos/ASIN/0814408796/metafilter-20/ref=nosim/ by James Lewis is a decent introduction, cheap ($10), and quick (160 pages).

If you lack a good mentor, Berkun's The Art of Project Management is an excellent resource that blends theory and practice. It is out of print, so check it out from your local library rather than paying $75 for a used copy on Amazon. It is an incredible resource.

Yikes! Who let The Art of Project Management go out of print? Boo to that! Without question, it's the single most important book I've read with regard to my job. That said, it looks like a new "edition" is out, but under a new title: http://www.amazon.com/exec/obidos/ASIN/0596517718/metafilter-20/ref=nosim/ Assuming its a logical expansion of the previous edition, it's exactly what you're looking for.

The truth is no one is good at estimating software project schedules. Ever. All those systems and gimmicks can be a little helpful in organizing stuff, but there's no substitute for good intuition and experience. One useful trick is to be explicit about time estimates for tasks, then go back when it's done and look at what really happened. With this feedback you'll eventually get better at estimates. The other useful trick is to never try to make a firm estimate more than two weeks out. Even more than one week is pretty uncertain.

In the course I took, we used Wysocki's http://www.amazon.com/exec/obidos/ASIN/0470042613/metafilter-20/ref=nosim/ (among others.) I thought it was a great book. It's thorough and complete, but easy to understand.

Do you track your time? At my company (which sounds like yours in terms of clients and project size) we have to file timesheets against broad categories: spec'ing, building, bug-fixing, etc. Then the programmers who are interested in this kind of thing try to draw trends from the reports. They also calculate a "burn down" rate by looking at the amount of work remaining in a project vs. the amount of time spent, and constantly updating an "hours remaining" estimate. It's like your average software progress bar, and about as accurate. (My technique is instead the time-honored "make shit up.")

One rule of thumb that may or may not be Berkun's is that estimates will slip by the same unit they are specified in. If you say something will take a number of weeks, it will slip in terms of weeks (and not days). Month-based estimates will slip by months, hourly by hours, and so forth. It may be helpful to think of the tasks as you're breaking them down into their subtasks (very important in estimating!) in terms of how you'd like them to slip (say 20 days instead of three weeks, for example). Then you want to practice telling people that tasks are slipping, because this is an integral part of keeping everybody on a project on the same page.

Thanks so much for your suggestions, everyone! This is really helpful and brings me a lot of hope. I think that between all these recommendations and the copy of http://www.amazon.com/exec/obidos/ASIN/0596007833/metafilter-20/ref=nosim/ that I'm making my way through right now, I should be able to get a better handle on things.

Running a Web Site? Agile / SCRUM frameworks are likely your best bet. http://www.controlchaos.com/, one of the best in the SCRUM business has a great site full of resources and he provides information in a very straight-forward manner including http://www.controlchaos.com/resources/. If you would prefer to take a course, http://www.agileuniversity.org/ aggregates the Agile / SCRUM courses that are available - at least in the US, while http://www.agilealliance.org/ seems to be more internationally focused and are also a wealth of knowledge. Once you learn the principles, http://www.rallydev.com/agile_knowledge.jsp (not affiliated with them but know their work) provides a really cool http://www.rallydev.com/community_ed2.jsp?src=aubanner1 as well as some great consultants to who could come in and help your organization get their priorities on track and train you along with your team (training management to prioritize is just as important as you getting trained). And http://www.chrisspagnuolo.com/ has been doing this a while and has some great first person experiences with getting a handle on projects using SCRUM and Agile. That should get you started. A search on Google for "agile" or "SCRUM" will take you further. Good Luck.