What can go wrong? The single biggest mistake I see planners make it to assume some aspect of "perfection" in their conversion of an estimate into a plan. Our estimates are not perfect; they need to encompass uncertainty. People are not peripherals: their performance is uneven and they can be distracted by many kinds of unplanned events. Efficient units of work don't always fit efficient division of required effort.

Planners need to take these things into account by introducing "slack": contingency time that can be consumed when adjustments are necessary but that accumulates when not used and can be "returned" to the available resources pool at the end of the project. At least that's the theory.

Resource Library:

Trouble is, slack tends to get used if it's available, whether it's needed or not. And if it's used but not needed it reduces productivity (because now it's just waste). So planners often "hide" the contingency from the team until it's needed, and that doesn't exactly foster an open and collaborative environment.

The second biggest mistake is to expect uniform productivity: the same amount of output from a day's input, every day. I have seldom seen this happen, even on projects that take a long time. It's much better to manage trends, where you can smooth the daily data into a useful indicator of progress, than to panic at the fluctuations on a daily basis.

Back in Project Management 101, we used to teach our teams to "plan the work and then work the plan." That's still not a bad basic approach in many circumstances. But it turns out that it isn't actually the best advice. Better would be to "plan the work and then adjust the plan as you go so that you get as close to the original commitments as you can." That's what effective self-organized teams do, and what pilots do when they file a flight plan. You have to have a plan to be allowed to make the flight (because you will be sharing scare resources with other flights), but it's really just a definition of what you intend to do, not an exact description of what will happen, which you can't predict exactly. Then you adjust as you go so that you get the safest result that's also the most cost effective, as nearly on time as possible.

This is called systems dynamics modeling, and there are interesting proofs that projects managed using these principles always ends sooner than they would have if they had been managed "statically": in other works, executed exactly as originally planned with no "in flight" deviations. The best project managers actually use this adjustment process intuitively (sometimes even when they aren't "allowed" to by the project planners). That's often why they are acknowledged as the best project managers: Their projects always seem to come in closest to expectations and without heroic efforts. (If you're interested in the theory behind system dynamics models, look for a copy of "Software Project Dynamics" by Tarek Abdel-Hamid and Stuart Madnick)

One very important caveat. Dynamically managed projects don't necessarily finish sooner than planned, or even on time. But they do (provably) finish as soon as possible in the context of whatever actually happens. It's very important to remember that distinction and be careful what you promise. All planning approaches have their perils.