If you work in a large team in a big corporation, and use conventional rather than agile approaches to web development, you may find this book very useful. It has advice not just on what tools to employ, when, and why, but also how to interact with clients and specialists in various roles during every stage of website genesis/ontogeny, from strategy to execution (via usability tests, concept mapping, wireframes and much more).
As a one-person band with a very small budget, I found big chunks of it rather idealistic, somehow old-fashioned, and not very relevant to my own circumstances. The usability / market research specialist? The information architect? Those would be me. The programmer? The graphic designer? Oh, those would be me too. And the person making sure that the words and images are suitable for the web as a medium? Me again.
I wanted some advice on best practice for (a) documenting decisions made (and reasons for making them) and (b) highlighting consequences of those decisions (and reasons) for future work. I was quite surprised not to see much discussion about how to document (b), which in my experience is often a huge hole in documentation.
Also, the processes I use are much more agile than those described in the book, which doesn't cover how to document development using agile methods. This is a shame, because I think more and more developers are moving in this direction.