Well it depends on your programming language, what I usually have, for C or C++, is as follows:

project
 |- bin/           (for binaries and required DLLs.. you can also have a lib folder)
 |   |- debug/
 |   |- release/
 |- data/          (for assets, such as databases, images, sounds, and so on)
 |   |- images/    
 |   |- sounds/
 |- doc/           (for your documentation, either generated or written)
 |   |- html/
 |   |- pdf/
 |- src/           (for the source code files, organize in subfolders)
 |   |- folder1/
 |   |- folder2/
 |- include/       (for the header code files, if applicable)
 |   |- folder1/
 |   |- folder2/
 |- misc/          (anything left that you want to include)

When it comes to DLL's, though, you might not want to drag around a bunch of common DLL's when distributing your program, so you might want to ask the user to install the required frameworks instead of providing the DLL's yourself, this makes it easier on you and ultimately on the user, since there will be no duplication.

As for how to get your program to find those DLL's, well, unless you are loading them dynamically, they need to be in the program's PATH variable for the system to find them, this PATH includes your system PATH (operating system library folder, and other programs tend to write themselves in this variable too) in addition to the directory where the program was launched, which generally means you need your custom DLL's to be right next to your program, at least under Windows.

This also applies to resources to some extent, so for release you probably don't want a bin/ folder.

If you use an installer you can make things more consistent, but this is more advanced.