The first thing I would do is read about the project and use it, from a user's perspective. Read the Software Requirements Specification (SRS), user stories, or whatever form of documentation exists for the requirements. Then, try to complete some of the core tasks and understand how the system is used. I feel that if you don't understand what the system is supposed to do from a user's perspective, it's incredibly difficult to design and implement solutions to problems these users are facing.
One technique would be to read design documents and follow through the code. Dynamic diagrams (sequence and communication UML models, for example) are especially useful, if you have them. These enable you to see a graphical representation of the relationship between code modules (packages, classes, and methods). Of course, static diagrams (class, package, object, deployment UML models) are also useful in understanding how pieces of a system fit together. If these diagrams don't exist, spending a little time reverse engineering the system might be a good learning exercise.
Given your situation, though, it sounds like documentation might not be available. The next option would be to use a debugger. Turn on the debugger and walk through the system as its running to see how it fits together. You can run through several common use cases and step through methods. It might be a good idea to comment files as well. Perhaps make notes of things that you question or need to learn more about.