What has worked?
How? Simple, compare two solutions, write up advantages and disadvantages and present them. Since you have already made up your mind, you're biased to the thing you want anyway. Your boss will usually see your point and make the right decision.
Where as, on the other hand, if you can convince your boss to dish out $200 a month per user for something like Author-It, you get an extremely powerful system that does everything an authoring tool is supposed to. That's what I'm trying to do right now with my boss, convince him to switch (not from Sphinx, but from another cheaper software solution called Flare), and it's not an easy task.
Tools that cost 4 figures seem to sit "just about right" in the managerial mindset where I come from.
Some managerial cultures seem to really ( _really_ ) want to see cash laid out for anything before they will believe it holds any virtue.
To answer op: Nothing. Been trying for a long time, but no luck.
1) Just use them. When you're demoing the product after a certain amount of work, explain how this new tool you've incorporated has benefitted the project in some major way.
I got Django accepted into the federal government doing this in what I believe was its first deployment (agencies don't generally talk, so there's no way to confirm that.)
Python was an accepted language, so I just wrote code in Django, explained how its use 'as a library' would expedite future releases, enable RAPIDER development and keep a clean, structured codebase, which was something they were having troubles with.
2) Choose products that actually DO provide benefit to the project. Sometimes it's hard, as a developer, to know the difference between "I want to use the Play Framework for this" and "The Play Framework is the right tool for this job." I often struggle with this myself, as I want to learn new things, and it's easy to get caught up in a new toy's feature list, and directly apply that to pain points you're having currently. When I was learning Ruby, I saw it as the tool to fix a lot of problems. Then, when I was learning Python, I saw the flaws in Ruby, and laughed at how I ever thought Ruby was the right idea. This isn't meant to be a slight on Ruby, as I'm guessing if I'd learned them in reverse order, I'd have had the reverse opinion.
It wasn't until well later that I got a good baseline for what each was actually better at (aside from the marketing points), and how to determine which one might fit a project better. It was even longer that I could make an emotionless decision to determine which actually made more sense _for a given project_.
If you have a real, valid reason to select a new language/framework/tool, and can both express the pain point to your boss, and illustrate how this new solution can reliably resolve that pain point without introducing equally sized, but different pain points, then it should be an easy sell. If you can't illustrate that, you might be a victim of your own personal bias. Don't feel bad, it happens.
Mention a competitor or partner company already using this tool successfully. Tell him what business metric will be positively affected by adopting the tool.
Timing can be critical so watch for the perfect moment to pitch your idea -- like ahead of a management meeting where your boss needs to talk up what your group is working doing.
But above all, be honest about the costs, benefits and alternatives. Good luck.
Give them an easy way to present it to their boss as their idea.
In retrospect, the answer was / would have been always to leave.
Not only does it reduce your productivity while increasing your frustration. It marginalizes you in your career.
Get out, and look for some place interested in helping you maximize your potential.
(Note: This assumes you really do know what the best tools are, for a given circumstance. Inform yourself -- don't just assume.)
* Where possible convert time into money.
* If it costs a lot of money, tell them how long it will take to recoup the investment.
* Give numbers.
* It is possible that your boss does not control the purse strings - so when you give your numbers make sure it's in a format that they can forward to their boss with few changes
Now, career stagnation, which is what you get if you never speak up, is a lot worse than getting fired, which is surprisingly easy to recover from as long as you have the savings. You just have to be aware of the risks of each avenue.
Managers also tend to underappreciate the importance of proper tooling in developer productivity (the commodity developer fallacy) and they tend to view such discussions as "distracting". From their perspective, Java's popularity is a vindication of its value. So many languages and methodologies have been oversold for decades and managers don't know which of these are real (e.g. functional programming, which provides a long-term 2-4x improvement in programmer productivity) and which are bullshit hawked by overpriced consultants.
What I've learned is that it's better to use the best tools anyway, deliver software using them, and use existing accomplishments to make your case. Results talk. It's better to ask forgiveness than permission. If you deliver something awesome that helps the company, people are going to overlook what language you used.
Also, some companies will not budge no matter how you present it you are better off working around the heavy process that is slowing you down. Or switch companies. Or voice you frustrations into the void of the internet like I did. http://objectatrest.wordpress.com/2012/03/27/one-process-two...
Each company is different and there is no silver bullet. You need to find out what the managers value (money, productivity, looking good to their superiors) and build a case on that.