Shipping software on time was and is a very hard problem. Actually, there are two hard problems involved. The first is knowing how to plan and manage development. The second is convincing stake holders that your plan is optimal and that any interference on their part—be it feature creep, dictating overtime, advancing the ship date, whatever—will make things worse. Please don’t consider the second part as me just trying to make a funny to capture your interest. It is a very hard problem in the real world.
There's a great book called Ship It! which is my favorite resource for this general problem. I prefer to focus on infrastructure, rather than management. I really don't know how to plan a project, not in any official sense, but I do know how to set up a project so that developers can work at their maximum possible productivity while ensuring their mistakes have the minimum possible consequences.
The specific subset of the problem emphasized here, though, is a pretty thorny one. It can range from a minor hurdle to a towering obstacle. It's essentially a political problem. It'll depend on your reputation, your luck, your organization's culture, and, in a few Dilbert-office cases, the personal day-to-day emotional lives and whims of the stakeholders in question. Developing a plan which really is optimal and really can't be improved by interference from stakeholders outside the project is definitely a less nebulous problem than convincing such stakeholders that you've done it, once you actually have.
The only book I know that really addresses these topics is Machiavelli's The Prince, which I haven't read since high school. (And of course the entire Dilbert ouevre.)
I do, at least, know one very good, very simple way to convince your superiors in an organization that your plan is golden: establish a kickass track record somewhere else, and if they question your plans, simply refuse to even discuss it. The downside to this method is that it basically draws a line in the sand, which makes it crazy overkill in most cases. The more subtle art of building buy-in from your stakeholders isn't really documented anywhere, but I'll agree with Raganwald, it's important, and it's far from effortless.
It's really a more general problem: how do you manage a team of people who speak one language, while working for a team of people who speak another? There's an ancient saying in Latin which means "Translators are traitors." It comes from the fact that the two words, in Latin, are nearly identical, but there's a modern equivalent. You've seen it if you watched the first season of "The Sopranos," when Tony Soprano sat down in his daughter's college and looked up to see the words of Nathaniel Hawthorne behind him:
No man for any considerable period can wear one face to himself and another to the multitude, without finally getting bewildered as to which may be the true.
Programmers should avoid modeling their social skills in the workplace on Tony Soprano's methods of dealing with stakeholders, co-workers, and competitors. But the essential problem, of being able to speak in business terms to business people and technical terms to technical people, is a problem which challenges anybody who puts one foot in each world. After a while, you wonder which world is home.
Planning for software requires equal parts planning for artists, in that you have to accomodate bursts of creativity offset by periods of no progress where people think about problems in the shower; planning in the usual corporate sense, in that you have to get people together and make sure they understand each other; and planning in the style of building a house, in that different kinds of interoperating systems will be built, by different kinds of people, and also in that a project without version control and automated testing is as secure as a house built without a foundation. Finally, once you meet all these requirements, you then need to defend your delicate balance from people who love to poke Jenga towers to see what they'll do.
I think the best thing to do in the event of Jenga-poking is to assume it will happen, and plan accordingly. I recently started on a project which had no version control. The first thing I did, I downloaded all the code and got someone to set up a Subversion repository. Literally a few days later, the entire system hit a hardware failure, and my manual backup was the only copy of the code we had access to. I hadn't anticipated that; I just saw the absence of version control and went on autopilot. It's just reflex - you see a system without version control, you add version control. Like spotting dirty dishes in the sink, you know what to do and it doesn't take long. Preparing for Jenga-pokers and their mischief should probably be as automatic and as reflexive. Expect interference, and have a recovery system in place for when it occurs.
What that recovery system should actually be, though, I don't know. That's the real question.