If the design isn't fixed yet (i.e. pins are free to be changed), then you have some flexibility in what goes where.
The first step is to determine what pins are absolutely fixed. For example the FPGA may only have certain resources on some pins - dedicated clock inputs spring to mind, as do high speed transceivers. Depending on the clock network some clock inputs can only feed some PLLs for example, so you need to decide early one where these clocks are going.
The second step, decide where interfaces can go - you want parallel interfaces to use pins close to each other, the last thing you want to do is route some pins only to realise that one bit of an interface is on the opposite side of the FPGA! This step also involves looking at voltages. FPGAs tend to have different 'banks' which each have different IO voltage references. You can't(*) have an interface running at 2.5V sharing with one running at 1.8V. You also ideally want all pins of a parallel interface to be on the same, or adjacent banks, preferably ones in the same corner of the FPGA (there are four corners, Top-Left, Top-Right, Bottom-Left, Bottom-Right, and each tend to have resources dedicated to that corner).
Once you have a map of where things can go, so you have decided your 16bit interface can use pins n-m or whatever, the exact order doesn't actually matter. You can rearrange in that group quite readily - because if picked correctly, the FPGA can simply remap the pins as needed as long as you were careful in your groupings.
Third step is to decide what layers interfaces are going on - try to minimise the amount of times high speed signals need to change layers as vias are nasty at high frequency.
Fourth step, pick any order in your grouping and start routing from the various devices towards the FPGA, preferably doing the most important ones first. Once you get to the FPGA, you can see what pins could do with being remapped - say you end up getting back to the FPGA with the data pins in an obscure order, simply reassign the pins to untangle them (easier to remap than to start adding vias to cross over each other).
Once you have a good idea of the mapping - maybe you've routed a fair few of the traces and are now confident that your choice of pins is routable. The fifth step is do a test compile - compile the FPGA and make sure it can use that pin mapping! I've had it happen to me once before that I've chosen assignments and accidentally used a dedicated programming pin for one bit in a data bus - I sent off the design without test compiling only to find out when the board got back that the one pin can't be used. The test compile will ensure that your pin mapping is compatible with the FPGA.
Note (*) Well you can sometimes, depends on the FPGA.
