Lots of coffee and sweets....
More seriously... you might want to start with checking the data flow first: which structures run in parallel and how do they communicate.
Maybe even try to pack some of them away into SubVIs in order to gain oversight.
Not a nice thing to do...
Maybe this document can help. I have only taken a very brief look into it
This may or may not be an option for you but, I find the best way to understand these things is to refactor them. I mean that I do what Oli_Wachno says and then take it to an extreme by cleaning everything up and instituting order that a human can understand. If there is a test harness you could wrap around this beast, you could continue to check to make sure you haven't broken anything. Otherwise, test frequently as you make changes. Given your description, it sounds like you received very poorly written code.
Refactoring code is refreshing to me and I enjoy doing it as much as writing code from scratch, possibly even more as it is both productive and amusing. Refactoring isn't for everyone though and if you are relatively new to LabVIEW, you might want to get hands-on help from a much more experienced developer. I always jam code that I refactor into a well-known design pattern (really several) so future developers can understand what is going on as soon as they open the block diagram.
Regarding the paper Oli_Wachno pointed at, I agree with the general concept of refactoring but have some comments. I have never used "Block Diagram Clean-up", and I have refactored a lot of code (including some garbage written by my younger self). Maybe one day I'll try it on something ugly and see what happens. I have also not used the "VI Analyzer Toolkit" for refactoring, though I have used it for final burnishing and clean-up.
I find that I approach a foreign VI a lot like I approach a block of foreign code in any programming language -- run it a lot and set probes and breakpoints until I see values that I recognize. Then start adding comments.
With LV code, you can often recognize standard patterns just by ignoring everything except the structure nodes and some key wires connecting them. Those provide framework to the program... You see a loop around a case structure where the case structure is about the same size as the loop? That's some sort of state machine probably. Find the shift registers on the loop and figure out what state it is holding onto... that's a massive clue to what the whole loop does. You see a cyan wire connecting two loops? That's probably data communication between two modules. Figure out what data is on it, now you know the relationship between those two modules, so it is easier to figure out what each one is controlling. Identify any LV classes or typedefs -- read their documentation (if you're lucky enough to have any) first... they'll add context to the diagrams that use them.