Short answer: I've configured Mercurial so when I ask it to do a binary diff (e.g. .docx) it uses docdiff
to feed both versions to MS Word
in compare mode--allowing me to see both revisions and the compared version of the document. It doesn't work for PPT because that POS program doesn't support comparison, but the other answers suggest Project does support comparison. Ostensibly, StackOverflow would be a good place to figure out how to properly configure Hg for comparing Project files.
Long answer on why I think VCS is a must, even when working with binaries
I've use Mercurial to store binary files (mostly MS Office). Version Control Systems may be at their best with text files because it's so easy to diff changes and so cheap to store deltas; nonetheless, I've found a VCS to be invaluable even for binary files.
Let me provide a couple of use cases:
Working by yourself: If you're the only author of a file and no one else can access your folder, it isn't that hard to maintain a canonical version of a file and dump old versions into an archive folder neatly organized by filename.
ground rules v01 20120102.mpp
ground rules v02 20120102.mpp
ground rules v03 20120105.mpp
The downsides are that you have to be a little OCD to keep this up and there's no easily accessible record of what's change from version-to-version.
If you put the same file in a VCS the commit comments can summarize what you changed. Obviously this isn't as precise as being able to see the diff, but it's remarkable how useful even a sentence or two will be in narrowing down exactly what version you're looking for.
Working in a shared folder: This example will either sounds like an insane straw-man or you'll be nodding your head in silent commiseration. Absent a version control system, yet still gripped by fear of throwing away data, binary files in a shared folder proliferate like bacteria in a petri dish.
Truly solving this problem requires a cultural change on your team, but you can do a lot better even if you're the only one using the VCS. I keep a repo locally, manually merge changes from multiple sources, check in revisions, and clone the repo to the server. It keeps the folder clean and all the old stuff can always be retrieved quickly thanks to the meta-data. The best part is no one even has to know it's a VCS; they just see a clean folder with an obviously current version of the file.
Unfortunately the merging is done manually, but that's a curse of binary formats without merge-tool support (and why I advocate moving away from them to marked-up text for documentation). (Not really an option for MS project files though.)
Another nice thing about this workflow is that because Hg tracks changesets and not revisions, people can edit different files all they want, and you can even check them in directly on the server repo. As long as the changesets don't stomp on the same binaries they'll pull and merge into your local repo no sweat.
Bottom line is there may be a way to configure Hg or some other VCS to push two versions of the same .mpp
file into project so you can compare the changes, but even if not, the benefits of storing the binaries in a VCS are incomparable, and with the good use of commit comments you should see a significant benefit.