For things like TDD, buy-in is extremely important: you are not the one that has to do it, your developers are. Test-Driven Development requires a bit of experience, knowledge, and creativity and a lot of perseverance to do it well. It doesn't work well for everyone, and dogmatic use isn't necessarily better than writing tests after the main code.
If you force them to TDD, you will get Test-Driven Development in name only, which will just lead to low-quality tests and code (maybe even worse than now) instead of the quality improvements that - I hope and assume - you want as result of this change.
But even for less creative, more mechanical changes, sharing the reasons (or reasoning) will usually lead to people being more accepting of the change, and knowing the reasons may also lead to them actually embracing the change and applying it effectively instead of only going through the required motions.
Better would be to get people 'from the floor' on-board in the change or decision process before final decisions have been made. This will usually lead to more informed and better decisions, and the people that actually have to work with it will probably be more accepting of it then something that feels like it is just being rammed down their throats.
Personally, if my manager would come up and say "You must do TDD", I would roll my eyes and wonder what management magazine or conference sold him on TDD as a snake oil that solves all software quality problems. It doesn't when applied without thought or willingness to really do it, nor without some flexibility (eg ideas for some tests only emerge when you have actually written code).