Money doesn't translate into speed per say. They can add developers or teams and break down production even more, but that leads to complexity and management issues and that actually might slow down development instead of speed it up. Best way to look at the budget is to ensure that it "will" get done and not use it as a metric to guess the speed in which it will get done.
I've never read the mythical man month book, but assuming more money/developers will speed things up is a classic manager thing that software engineers hate.
The normal manager argument is, a task takes 9 "man-months" (please excuse the "man" term and blame corporate culture
) , so an engineer will work on it for 9 months. But what if there were 9 engineers?! They could finish in 1 month!
The normal engineer attempt to explain how this is not necessarily a good plan is, 1 woman can have a healthy baby in 9 months, but 9 women can't speed that process up to 1 month.
Presumably once management backs off on this, they go for the next classic management strategy -- "We'll keep the same team then, and you can all work [maybe paid, maybe unpaid] overtime. Overtime is totally productive and doesn't cause people to burn out, make mistakes, and kill themselves, right?"
