Missing the deadlines isn't horrible. Open loop control is all about precision components and carefully controlled conditions. Humans working on projects they have never done before are not precision components, and if your software project can be described as carefully controlled conditions, you work on different software than I do. So, it's no wonder that we need negative feedback loops to make it all come together. However that requires that people admit when they are behind as soon as they are behind. Needing to readjust deadlines either by changing the task, time or resources is nothing something that you either as an individual contributor or as a manager should be penalized for or feel bad about if it happens incrementally or when problems are discovered.
All too often though, it works like this. "How is your deadline for Friday coming," the manager asks. "Fine," the programmer says, thinking to himself that while he hasn't gotten started he can work extra hard and get it to come all together. Friday rolls around and the programmer says, "it will be done real soon; a bit to finish up," as he starts coding madly. Two weeks later, this project that was on-time two days before it was due is mostly done. Adjusting deadlines is fine but 600% over-budget is not an adjustment, it's a major failure. Yet 600% is not uncommon for the sorts of problems I've seen within MIT or especially on volunteer projects. If the manager had known it would be two weeks then the project could have been reassigned, additional help given, or the feature set changed. But if the deadline is always just around the corner the only thing the manager learns is that they have an unreliable contributor.
One factor that significantly contributes to the problem is that a lot of people are very interrupt driven. They may well be only two days behind assuming they could find a two day time slice. That might happen next month. I haven't yet figured out a solution to the interrupt driven person problem that works well. I guess if you could estimate time slices and how often they happen or estimate what fraction you'll actually spend on a given project, you'd be able to do something useful. That doesn't always seem possible. I've mostly had to write myself off for anything directly related to Kerberos other than management: I just don't have predictable enough availability that I can count on anything assigned to me getting done.
The take home lesson here is simple. Give your manager as up-to-date information about how well you are doing on your projects as you can. Honesty and accuracy is so much more important than telling someone what they want to hear or being optimistic. Yes, you want to be a team player: you want to say that you will meet that deadline and help the team get in those extra features. However reality will tell and in the long run unjustified optimism hurts the whole team as well as hurting your evaluation.