Opinion: The Perils of Project PlanningBy John Parkinson | Posted 07-28-2006
Opinion: The Perils of Project Planning
In my last column, I wrote about the challenges we face when trying to create a useful estimate of the effort required to complete a software development project and the methods available to do so. As challenging as this is, it's just the start of our journey to a predictable project outcome. Now we have to take that estimate and turn it into a plan that will allow us to "manage" (from a root word that meant "keep a hand on") the work.
Let me start with a couple of important observations:
First, for small projects, and experienced, self-organized teams, a formal plan may not be necessary. Such teams have a good sense of how long it will take them to finish and are good at assessing what they can commit to. In these circumstances, formal plans may serve other roles (perhaps as a framework for collecting information about what actually happens or as a template for reporting progress). But they won't enhance the project team's work. That doesn't mean that smaller projects don't need to be planned for.
Second, the variables and constraints we work with when we plan are not independent. As I add resources to a team, I add coordination overhead (and maybe other kinds of overhead as well), so the proportion of non-contributing resources goes up, and so do my costs.
There are also intrinsic rate variables to consider. I can't get 100 days of work done in one day using 100 people if some of the work takes a minimum of 5 days. (This is a problem of "irreducibility," and it often gets overlooked. Nor is it always obvious to the estimators and planners, or even to the team members. (If you're interested in the theory of irreducibility, look up the work by Greg Chaitin at IBM Research.)
Absolute duration also matters: The longer the project lasts, the higher the probability that I will have to adjust its scope and the more review and re-planning effort I will need.
We also want, wherever possible, to achieve "resource leveling": keeping the project team the same size throughout the project, which helps achieve the best utilization without making some people split their time across more than one team, which generally reduces their productivity within any one team.
And finally, we have to factor in differences in ability amongst the team members. Ideally we would like to assign the work in amounts that matched exactly an individual's ability to deliver. Unfortunately, we seldom have enough knowledge to do this perfectly, and people change enough over time to make past performance an uncertain predictor of the future.
So planning is really an exercise in tradeoffs and compromises. Planners (and their tools) try to get the "best" answer from each situation by "fixing" one or more of the variables and optimizing against the rest. So we fix duration and vary effort and scope. Or fix scope and vary effort and duration. The most sophisticated tools run through millions of combinations of possible tradeoffs and propose one or more "optimum selections" according to defined characteristics like cost, delivery time and resource utilization.
Then someone makes a selection and you're off to the races.
What Can Go Wrong
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.
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.