FxCop is pretty useful. No, really. Automated code review type thing. Sort of. And here I am about to give you the best FxCop tip in the world. Well, actually the best two FxCop tips. Ok, make it three. Ah stuff it, here's a whole bunch of them.
First top tip - unless you're using the version of FxCop that's integrated into Visual Studio (I'm not), you'll want to define the CODE_ANALYSIS symbol in your project settings. This is because the SuppressMessageAttribute class is decorated with a ConditionalAttribute with the CODE_ANALYSIS symbol. In other words, the SuppressMessage attribute will be ignored unless you define CODE_ANALYSIS. (Only define it for debug projects. Consider that a bonus tip.)
(Of course, you might actually want it to be ignored to stop over-zealous/lazy programmers suppressing FxCop violations instead of fixing them. But hey, let's try and stay glass half full, eh?)
Here's one I prepared earlier - ensure your spell check language is consistent across all users. And the top up tip is to ensure that you're all on the same version (and service pack revision) of Office.
The FxCop team blog provides a way to run FxCop as part of a normal build, including a bug and workaround. But this doesn't use a project you might have set up, so you might want to give the FxCop msbuild task from the MSBuild Community Tasks Project, or just play about with the /project command line option. (This blog post has more details on FxCop/Visual Studio integration, including a link to an FxCop addin, that I'll have to have a look at.)
Speaking of projects, FxCop bizarrely saves the messages to the project file after each run. The advantage of this is that you get to see what's changed between runs, with new messages displayed in bold, but you do need to have the file checked out each time you run an analysis. If you don't want this, uncheck the option to save Active messages in the project. You still want to keep exclusions checked though - that's a change that you do want saved. Alternatively, you can save active and excluded messages to the report file and use the /import switch to FxCopCmd to get it to read those files. This way, your project file doesn't have to change at all, but managing the reports in source control could get tricky. (I feel a post analysis script coming on...)
I think that last paragraph can be summed up simpler - read the docs. Or at least, read the "Managing FxCop Projects" page. It's dead easy to get started with FxCop, but once you start to get a bit more advanced, it's not terribly obvious what's going on. And if you're putting FxCop into a build process, you'll really want to read through "Using FxCopCmd".
But the number one best FxCop tip? Simple. Run it from day one. Don't let the violations back up, or you'll never bother to clear them down.