Revised 17 December 2010
Project plans aren't discovered, they're designed. More to the point, project planning is process design.
For any particular project, the plan can lay out the work in a long string, using a small team for a long time, or it can break the work into relatively independent components and have lots of people working in parallel for a short time. The first approach, essentially Agile, is the most cost-efficient because it has less coordination and integration overhead. On the other hand, the longer a project lasts, the more likely it is to be impacted by low-probability hazards and scope creep. The longer the plan timeline, the greater the uncertainty in its outcome.
Consider the usual approach: The project work is broken into components and the dependencies between components are identified. The result is a graph where each component is scheduled after the components it depends on are done. The dependency graph (with some numbers added) becomes the plan. For a non-trivial project, this is hard work that no one does twice but, as we'll see, they should.
The problem with that method is that the first-cut dependency graph is only one of many plan designs, and probably not the best. If the important factors are high quality and low cost, the plan can be strung out so it's built one component at a time by a small dedicated team. The dependencies are accomodated, but they don't drive the plan design, and we know that, in general, the best products are produced by small highly focused teams.
If time is of the essence, the component architecture can be refactored, or dependencies can be circumvented with stubs and careful interface definition. Either or both of these will allow more parallel development than the initial dependency graph, but at an increased cost--And the risk profile is not at all like the risk profile for a strung-out plan.
In a compact (high concurrency, lots of people) plan, most of the risk is from miscommunication. Also, because the timeline is shorter, it's more sensitive to overruns in individual components. On the other hand, the main risks to the strung-out plan are exogenous events.
Project planning is process design--a design that needs careful consideration of what the project is to achieve, analysis of the factors impacting success and management of the relevant risks. Mechanically turning the important decisions over to an ad-hoc work breakdown structure and project management software is an abdication of responsibility.
In healthy organizations, there are consequences to failure and managers understand trade-offs. They want more than to just have a project approved; they want the project to succeed. We fail them by not baking all the risk factors into the plan, by using faulty planning and estimating tools that give persistently optimistic results, and by not giving them a choice of plans with an opportunity to trade risk off against time and resources.