I had to do this at my last gig, only the shop had a very ingrown and long-established culture..."the design is in the code", "if the code is right, no one has to read it again", etc.. The approach I took which was at least moderately successful, was to first take the MS standards as the starting point -- they are pretty good and more importantly they set the tone for what is important and what is not. Stay away from the silly stuff like cunting comments or the number of spaces inside of comments and concentrate on what makes reliable, reusable, and readable. The second and more important aspect was to get the affected people involved early in a series of ongoing review/feedback opportunities so everyone felt like they had a chance to contribute. These don't have to be meetings - just post the in-progress standards somewhere and let people know they are available and you are taking comments. Those that are truly interested will participate, those that aren't ... they missed their chance. Also use 'guest authors' for specialty areas like .MSIs and SPROCs -- they know what is really important in their areas of specialty. We wound up with a set of standards and 'advisory' items which everyone pretty much adhered to, and that required a minimal amount of maintenance/updating on my part as MS went through its regular convulsions (er, new releases). Finally, make it clear that you have management support and that adherence to the final standards will be part of automated code reviews and individual performance reviews (you did get management buy-in at the beginning, right?). And of course, don't forget your body armor :suss:
“The trouble ain't that there is too many fools, but that the lightning ain't distributed right.” --Mark Twain