One more option: We hold periodic "reflections" on our process with all the programmers on a project. Part of this practice is to do a "root cause analysis" on the bugs that have surfaced recently. What caused this? Was this a regression? Was this a lack of IE6 testing? Would asking Joe about this helped? The goal being to figure out why we are having those bugs and what we can change to prevent them.
If code reviews are an appropriate tool, this will come out during the discussion. And it will be the programmers themselves who introduce it, and so you will get much more buy-in from the beginning. We agreed that all code needs to be reviewed before it's checked in. Developers generally ask for it, but if they forget, they sheepishly admit it... they know they aren't just defying "management", but going against the team's agreement.
(Or if it's not an appropriate tool, people get a chance to explain why.)