That is a very common problem with parallel computations. Technically, if the communication pattern within your MPI-parallelized code is complicated enough, even runs with the same number of processors might end up having slightly different results.
Now, the strategy to deal with that will differ a lot depending on what and how is being parallelized. One of the common sources of "results fluctuation", is the reduction (due to non-associativity of floating point operations).
There are several things you can do about that.
First, look at this CompSci question on MPI reduction reproducibility. Jed's answer gives a nice overview of the problem regarding reduction and an advice to have stable results for the same and the different number of processors.
In short, do your calculations in parallel, until you need to "merge" them together (reduction). To merge them, gather them on one processor (commonly referred to as the master node) and perform the required set of operations. When doing the last step locally, you can be in charge of the operation order.
However, the reduction is not the only possible source: as your problem partitioning (mesh partitioning, etc.) might already introduce another source of "fluctuations". So, I would suggest
- to reevaluate your criteria on independence on the number of MPI processes
- if you decide you need it, to have both (more) stable, debug, but slower version, and standard one.
- have some tolerance to which you would allow the results to be different.