It sounds like the process of code reviewing has sorta begun. It hasn't as an official thing, but a rumbling under the feet of your development team. There are two sides of the issue, those who care, and those who don't. Obviously you are one of those who do care.

Code reviews establish one and one thing: Is what you are looking at 'good'? New code, old code, code from last month, is any of it worth anything. The biggest gain you earn is akin to the opensource idea of "many eyes". You can witness, if you haven't, many solutions being posted on pm that have small mistakes, but have been caught by someone else.

You have a few argumenets usable for management if you need to convince them that should you make the slightest change for the better, it is for the better. Better code means easier maintenance, simpler design, faster updates after refactoring etc ec.. there is a return on acting upon fixing bad code. I suggest the refactoring text by fowler on this. He has a good 10 pages on interacting with manglement on this issue.

As for the best way to review? I'm guessing there is no design document. Start from the biz straight down to the code. A task needs to get done.. (use case) This task involves doing these N steps with certain conditionals in a certain direction. (activity diagram for the use case). The data is stored as such (class diagrams and entity relationship digrams) using these bits of logic. (in code documentation, class diagrams, sequence diagrams etc..). As you cover case by case, you'll slowly envelop everything. It's a bit of systems analysis and design with an existing project/product.

Being a tech person, your biz cases need not be the best MBA (Master of Business Administration degree) speak in the world. If your biz team helps you, you'll have the definitive manual on your system. And when you make changes, anyone can browse the manual and figure these things out. More importantly, you'll know the relationships and dependencies of how everything works.

Update: MBA cleared up (tnx davis)