The enterprises that think that large software projects can be completed with "pay X get Y" are the ones that fail, historically speaking, because software projects are subject to a much higher risk of budget and schedule overrun than other types of projects (such as civil engineering projects). Large IT projects have put more than a few large companies into bankruptcy.

Yes. I think the solution to this is to get rid of budgets, and go for an approach based around iteration, risk reduction, and a flow of delivered value.

That sounded insane to me at first, but the Lean folks really turned me around on this. Mary Poppendieck's books are great in this regard. One of her best examples is the Empire State Building: they started construction on the lower floors before the top floors were even designed. Nonetheless, the project was completed on schedule and budget. How? As with Agile projects, scope was treated as variable, and a lot of thought was put into maximizing efficiency of the system.

I've also read some great stuff from the Lean Manufacturing community on how shifting the approach to accounting is vital. Rather than having annual plans and budgets and then trying to hit them, you have rolling projections n months out and adjust allocation to achieve real-world effects.

Yup. The problem is trying to explain to a client: "Ok, so we've got the 4 best back-end developers, 2 best UX/UI guys, and a scrummaster. Now they'll cost you $100k/month, and we think that'll create 3 apps for you, but ummmm we're not sure. But these guys are the best, so on average you'll get more production out of them if you don't do agile" My conclusion is that agile only works with talented people; most of the enterprise clients I've work with (non-SaaS stuff) don't care whether they are Linus Torvalds or Joe Shmoe, they just want to spend their budget and get their "app" within the budget.

I think if it's a client situation there are ways to use Agile approaches and still give them fixed bids. The initial setup is wasteful, but from what I've seen once you deliver regularly you build trust, and they learn that they can control risk in other ways.

As to talent, I have the reverse view: by putting people in boxes, waterfall-ish processes train people to look untalented. I think perfectly ordinary people can do Agile processes as long as there's good mentoring and institutional support while they learn to step outside their boxes and make shit happen. After that, nobody wants to go back to being a doll in somebody's Manager Barbie Dream Office playtime.