Why are projects so frequently late/over budget?

There is also confirmation bias.

Recently my town built a school, it came in $4M below budget. The discussion of this savings lasted about 10 minutes and included one article in the local paper.

More recently, my town is planning to create a pedestrian friendly “streetscape” along one block of our business district. You know, wide sidewalks, benches, planters, etc. Bids have come in $250K higher than the original estimate. The wailing and gnashing of teeth has gone on for over a month and I know it’s not going to end for months longer.
In addition to this, there is a limit to how under budget you can be, there’s no limit to how much over budget you can be, so the over numbers are frequently going to be bigger, and more interesting to read about.

I’ve refused to take on projects that don’t have realistic timelines. Sometimes someone with a half a brain realized I had a point and rescheduling was done. Other times I gained because I was a contractor and they had to come back to me when the project ran late and overbudget. Sometimes I was able to explain that the project could be completed in the predetermined time by scaling back the requirements. Other times I didn’t get involved at all, and I never regretted it. In my business I saw a number of projects get started which were NEVER completed.

The why part is mostly lying.

Every project has at least two tiers of workers - management and actual productive workers. Management get pats on the back for having everything going to plan. Actual productive workers just want to make good product.

So when you ask the APWs how things are going, they tell you about all the problems. When you ask management they lie about all the problems.

Suddenly in one week the project falls 6 weeks behind (actually happened) or arguments begin about what will be delivered in the rollout or suddenly the user requirements are the problem.

If one of the requirements for working on a major project was assiduous honesty we would have far fewer “surprising” fuckups. But there would only be 3 or 4 project managers on the face of the earth.

You’re missing one key component. Typical project planning works more like this:

  1. Management provides vague requirements
  2. Plan including assumptions to cover requirement gaps is created for 1 year, 1 million dollars
  3. Management approves the project to proceed with 3 additional requirements a 750,000 budget and a schedule of 9 months
  4. Project completes in 1 year and 250k over budget.

I wouldn’t characterize most of it as lying. Usually these people have no idea what the truth is.

That’s probably the most true assessment; the business guys have a problem going too far down the rabbit hole of analysis and requirements gathering without an estimate, but to get an accurate estimate, you have to go down that rabbit hole.

So IT departments tend to peer into the hole a little bit, sometimes with a flashlight if you’re lucky, compare this to other rabbit holes in the past, and then give an estimate based on that.

Often true, but I was on a microprocessor project a a very large company where all these rules were followed and the project was still incredibly late. There was no feature creep for once - the architecture and microarchitecture specs were set in concrete. Progress was tracked closely, and it was clear what was going on - though top project management often didn’t want to admit it to their bosses.
If you’ve taken the tutorial for project management software, you’ll know that the examples they use are putting on a play or building a house. That gets done on time. What this software doesn’t cover (at least not the last time I used it) is the effect of rework. If you did everything right the first time, you’ll be on time. You can put in a box for debugging, but that is way too simplistic. Bugs might take hours or weeks to find and fix. A lot of effort in hardware is spent in putting in features that exist primarily to help in debugging. This costs money and area, so you need management and design teams that have gotten burned in the past to make it happen.

The other factor not explicitly mentioned is that there is often a push from top management to cut times. Your manager might create a realistic schedule only to see it cut. This isn’t stupid - introducing a product sooner often increases its profitability a lot. If the manager pads the schedule then cutting it is good. If the manager doesn’t pad the schedule, all sorts of bad things happen.
Reducing complexity helps a lot also, but can hurt competitiveness.

I’m talking big bleeding edge projects here, not accounting software.

Since you ended up with 4 answers, I’ll just assume it was feature creep.

No one does. Progress is nonlinear, especially when rework is involved. In many cases people are 90% done for 90% of the duration of a project.

Consider testing. How do you know when you’ve finished testing a piece of software? Finding no bugs might well mean you haven’t tested well enough. The answer usually is when the bug discovery rate flattens out to a reasonable level. That isn’t something easy to schedule accurately, especially for new and major projects.

Yes! Do not walk into my office, look at me and ask, “How long will [x I have no prior info on] take?”.

My answer will inevitably be, “Go away so I can spend time researching to give an accurate response.”

That’s true in that respect. But a lot of upper management is woefully unable to evaluate what’s going at the lower level. Even people who were once technically competent can be hopelessly out of touch in just a few years. Their problem is they don’t know what they don’t know. And of course the 90% stuff brings up this:

I call this Pyramiding. Some brilliant designers go to work on the new design for the Pharoah’s pyramid. They start by making a model of the pyramid. They claim to have made the important decisions, how many sides, the angle, the size of the base. Then they’ll point at the model and say “Look this is exactly what the final piece will look like, we’ve designed it in detail all the way to the last step!”.

If the pyramid doesn’t collapse half way through construction because they didn’t bother with good specs for the foundation (that would make the job look too costly and not show progress fast enough), at least they might get buried with the Pharoah.

As far as testing goes, well that’s a thread where I could rant long and hard. There’s not enough time now to even get started, BECAUSE SOMEBODY DIDN"T TEST SOMETHING!

Don’t forget the Efficiency Penalty. An unavoidable consequence of any business model based on creating something or providing a professional service for others is that there is frequently a strong disincentive among the APW’s to finish early or under-budget. It’s even worse if one of the metrics by which your job performance is judged is billability (i.e. the percentage of your time that can be charged to a project and not to company overhead). It’s not a problem if there is ample work in the pipeline for the foreseeable future, but if there isn’t…

“Goofus has let his project slip. He will continue to be highly billable through his lackluster efforts on the project and may even force his company to accept more money from the client. Gallant finished his project early, leaving 20% of the budget unclaimed, and is now getting paid to do nothing while his manager has to do extra work to find something for him.”

At some point APW’s realize it’s in their own interest to be Goofus. To put it in terms of the OP, it’s human nature to follow incentives.

Ahh yes. Always management’s fault. We don’t know anything. At least we’re smart enough to get away from the day to day crap of actually having to do stuff!
As others have pointed out, unless you have built the same exact project multiple times (which is rare), it is nearly impossible to accurately predict how long a project will actually take to complete without planning that project in such detail that you have effectively done it. There are all sorts of PM methodologies - Waterfall (lets plan everything in stages), Agile (lets work on everything in pieces), scrum (fuck it, just everyone work on something). Yet projects still go over time and budget.

A lot of it also has to do with how projects are sold. It’s a lot easier to under estimate a project and then tack on additional work if required. The client is already emotionally and financially invested in the project and more often than not, it is impractical to start over or pick it up with other resources.

But mostly, it’s simply impossible to account for every single contingency on any project of sufficient complexity. Especially one where you have to come up with new and innovative solutions to never before seen problems.

Well, you can, but then you have Apollo which landed a dozen people on the moon in 8 years or so at the cost of a zillion dollars. I heard Burt Rutan speak, and he said that if they did it like the beginning of aviation, where pilots died, it would have been a lot faster and cheaper.
You can account for nearly everything, but you’ll never get funded.

Don’t forget, Apollo lost three astronauts on the launch pad in a fire on the launch pad which no one had anticipated, and kept another three from dying only because they were able to improvise solutions for a problem no one had anticipated.