The "Angry Aussie" blogs on a wide variety of topics, and the posts under his Work tag are on the front line of Workforce 2.0. I agree with his philosophy about scheduling and project management:

A business can use a project schedule in one of two main ways: as a weapon with which to beat the project team if they fail to deliver to schedule or as a general roadmap. To those who treat divergence from a schedule as a failure which must be punished: you’re going to get the team, the morale and the results you deserve (hint – they’ll all be crap). But if you acknowledge that your schedule is a best guess at where the key signposts are, that you’ll have to stop and ask for directions regularly and that you’ll find the journey taking you in strange and unexpected directions before you reach your destination, then you stand a chance of success. (The full post is here.)

Instead of managing a project to death, I think the best way to run a project is to follow these general steps:

1. Create an initial project plan including a project work breakdown structure.
2. Tentatively request and book the resources to the project, but at the project level, not at the task level.
3. When the project is about to be initiated, review the plan once again and make any changes.
4. Finalize the project team, and assign members to specific tasks.
5. Publish the plan for tracking purposes.
6. Track the project and every once in a while, compare the actual effort and estimates to the project baseline (the plan prepared step 3). Define new baselines as required.

As these steps suggest, the project plan and the original resource bookings are really forecasting and planning tools. Most projects experience a lot of changes that make the original plan obsolete. After the initial plan, what most project managers need is a good effort tracking system to measure the project’s true cost and performance against the original or revised estimates.

But as Angry Aussie suggests, using a detailed project plan as a means to over-control a project from start to finish, or to cast blame as soon as reality deviates from the plan (which it always does), is folly. The effort expended to exert so much control over projects will blow out the schedule and budget (if it does not scare away any good people you have) just as surely as the "unknown unknowns" that derail every project plan.