How to choose a methodology
I think I (and many others) have written pretty much the same thing a gazillion times:
Of course people still keep asking the same question (what is better Git or XYZ), so maybe it does still need exploring. You've highlighted the need to determine the management vision, and the requirements, but my experience is that finding those out (and putting it in a language everyone can understand) is the stumbling block. People give up and simply resort to: this one integrates with abc, or this one has a nice GUI. Them's not management requirements folks (and integrations and GUI's are simply a dime-a-dozen).
Tools go in and out of fashion indeed. There are a few considerations:
1) Is it open source? This is not about getting free stuff but about long term viability of the solution as well as integration options. For example Perforce is closed source, which means it is largely ignored by the OSS community. This impacts you when doing continuous integration, setting up deployment tooling, etc. You'll find few people with relevant experience setting it up or using it. Most IDEs won't support it. Etc. Kind of makes it a really sucky choice regardless of its other qualities. Google chose Perforce when CVS was mainstream and Subversion had not been released yet. It's the same reason Linus Torvalds opted to develop Git instead and skipped subversion entirely (he wanted an OSS solution). I suspect, large parts of Google's code base are in Git repositories these days. As a professional, I steer clear of anything proprietary. I have zero tolerance on closed source components in my software or tool chain. Rarely worth the trouble bothering with proprietary stuff.
2) Is it up to date? When picking a new tool, betting on something that is out of date is foolish. Tools that have become unfashionable rarely become fashionable again. If you use subversion, it is time to look onwards. Git is mainstream now and has a bright future. Btw. Git-svn is a superior svn client, useful when stuck with outdated infrastructure.
3) Is it mainstream or am I taking a bet on some oddball solution? Git used to be the latter but has now become the de-facto choice across the industry. Sometimes these bets pay off. However, most of the oddball Git alternatives failed to get much traction.