If the project requires logic that I haven't already built something for I'll do a quick logic diagram. But I'm the type of programmer that likes to see how things work and then modify the code on the fly to make it better. Which means simply, that if I don't like how the user must interact with the GUI or I don't like the way the code logic feels as I'm working with it, then I change it. I can be pretty anal-retentive when it comes to solving a problem - even if it's only for a small gain.

Do I do an as-built? No. I do stuff in comments in key sections. I will sometimes fill in a form that identifies a file, the queries and variables and describes what it's used for but I try to give my files descriptive names with just enough comments instead.

I have used flowcharts for some things, and found them to be quite effective. When you know what you need and where you are going it can make things seem a little clearer and make the project a little less daunting. I also find I end up with less silly errors. As for advice on building them I really can't help you, I've never had formal training, but I just like to sketch out some information flow.

Thanks for your insights- I think presenting yourself with the big picture before a large programming project has to be good. There's probably no set way to organize your information but for reference some proven methods for flowcharting would be helpful.