As an IT project manager, I brought in a few projects on time, on budget and in scope. And many that weren’t. The one thing in common on the “successful” ones was the support of management up front to take the budget as given as necessary, to not permit scope creep, even a little, and to take a “this is important, you will get it done” note with the project teams. The ones that were unsuccessful started out underfunded as the budget was “negotiated” (we will do this project but for 70% of what you say it will cost), had scope creep (or a poor understanding of the scope when it was budgeted and scheduled), and had a project team torn five different directions for whom this project was one that wasn’t the HIGHEST priority. Many many times the subject matter experts would be telling upper management early on what the problems were going to be and were shut down for a pollyanna view of the project. Or they’d cut entire necessary organizations (like eSecurity - no one like eSecurity, or Vendor Management) out of initial discussions because they knew those organizations would bring up issues that would make the project more complicated.
If you aren’t honest with yourself up front, there is no hope. But I came to believe that corporations don’t want honest up front because they’d never get approval for five years and $30M.
The bigger the project is, of course, the more places you will have variance in your costs and schedule. So its far more possible to deploy small pieces of code in the time you expect with the staff you estimate - and highly unlikely you will be able to migrate to a new ERP system on time and on budget. The small ones are likely to be internal projects. The big ones tend to be the ones consultants are brought in for.