Two months into my first job out of college, in the Tokyo offices of a large U.S. investment banking firm, I received an e-mail asking me to verify figures to be presented to the Board of Directors in New York, describing a 65% reduction in trades processing costs, and predicting a similar improvement the following year.  I nervously asked the head of Tokyo operations if he could show me how he had arrived at his figures, and he gave an exasperated sigh, and demonstrated how he'd taken the (unusually low) daily trade volumes from January, plotted a straight line through the current month of August (when we were experiencing the highest trade volumes in the firm's eight year history in Japan), and then simply EXTENDED the line for another twelve months.  I stood there with my mouth open... and then hesitantly pointed out that projecting the growth of an embryo would give you a one year old child who was a hundred feet tall, and that his figures assumed fixed costs, while I'd already heard we were running unsustainable levels of overtime, and adding staff might require leasing more office space in what was, at the time, the most expensive real estate market in the world...  He said that, since these numbers were my responsibility, he certainly wouldn't present them to the board if I wasn't comfortable with them...

Flash forward a few years, to a massive effort to completely revamp a company's flagship client-server software product, requiring coordination between engineering teams in europe and the U.S., involving new technologies like WCF, Windows Forms, and ADO.Net, applying new development procedures like unit testing, FxCop oversight, and comprehensive code review for the very first time, and involving more than a few developers whose skills were... less than optimal.  I'd been pushing to have the entire local team work closely with the two of us who had significant .Net experience, to try to generate, as quickly as possible, an installable, functional UI shell, over a minimal (but architectuarally accurate) remote comms/data access framework.  This would let us iron out basic code quality, architecture, and dev. process issues AS A GROUP, and give us a more accurate basis for monitoring progress, as we gradually added features to a production quality base.  The project manager vetoed the plan, saying we couldn't have everyone working together on the same tasks, and that we had to come up with a detailed schedule.  Three years of tasks were therefore broken out, assigned to individuals to estimate, interdependencies carefully charted, and tasks then reassigned to DIFFERENT individuals for implementation.  Several months later, we had a collection of untested, independently-designed feature FRAGMENTS, which had yet to undergo a single code review, with no idea of when we might ever see a running executable representing the actual integrated product.  After the third panicked meeting in a single week, on how to address feature schedules already double their original estimates, with the discussion focused mainly on the possibly of cutting features (with a ship date still TWO AND A HALF YEARS AWAY), and the need to revise estimates and reshuffle interdependencies in MS Project, not to mention the PM's comment that she hoped she wouldn't have to cancel everyone's vacations for the duration of the project... I announced my resignation.

Reality doesn't conform to carefully "calculated" projections.  As a software project manager, your contribution is not to tweak Gantt chart or MS Project scenarios, but to help identify, and RUTHLESSLY ADDRESS, issues interfering with the optimal performance of your team, adjusting any initial estimates or predictions based on observed (hopefully, ever-improving) results.  No amount of estimation is going to help in the situation described above, without first establishing some actual BASIS for making estimates.  Developers still need to identify tasks, and provide estimates in no larger than half-day increments, but focusing mainly on the subset of features they are ACTUALLY PREPARING TO IMPLEMENT.  Unless you are building a virtual copy of a previously implemented product, involving the same group of individuals, working with identical technologies under the same process... you just have to accept the fact that any detailed time estimates farther than 3 months out are very likely to be VERY wrong, and adjusting those estimates shouldn't be treated as anything other than a natural, expected part of the development cycle.  Obviously, detailed estimates are intended to avoid a situation where you approach the "end" of a three year project, with no clear idea of when, if ever, the product will actually be ready to ship, and modern "agile" methodologies try to address this by advocating the creation of a production quality framework as quickly as possible, by prioritizing features to ensure the most important items are addressed first, by requiring all code to be fully tested and of shipping quality at the time it is written, by not saddling the project with subpar performers or senseless beauracracy, and by defining short intervals at which to re-evaluate the schedule and feature set, based on open, honest, evaluation of OBSERVED results.