It is a bit of an apples to oranges comparison, today I was really struck with an benefit for the agile approach that haven't really appreciated. On the classic project there is a distance or an understanding gap between the formal project plan and the people doing the work. On the classic project many people just don't have the time or care to become familiar with the schedule or the project plan. If they do, they are primarily just looking at the end date and maybe what is on the critical path to the end date. It is a project manager's job to drive the planning process and make the team aware of what is in the project plan. But most of the time they really don't care beyond the success of the project. They have developed some kind of understanding what what needs to be done and that's what drives them. Especially in a matrix organization, the project manager is often some one running ahead of or along side the project trying to keep the plan aligned with the reality of the performing team. In a matrix organization the resource manager will have language and vocabulary for talking about what needs to be done, it should be but it is often not exactly how it is described in the project plan. A good project manager will have some standards for describing tasks or doing the work brake down structure. This may be very professional and orderly but it is often not how the resources would typically describe the work to be done. IOn top of the semanict and vocablary issues the plan may be captured in a tool that not every person has due to license cost or just convenience. Consider a team of 12 where on the only the project manager and the resource manager have a tool like MS Proejct Professional and their dest top. The other 10 on the project get PDF reports, PWA access, or get to watch the project manager use an overhead projector to display the plan on the wall.
Some resources may passively resist the regimentation and structure that comes from working on a formal plan maintained by a professional project manager . I believe that all of these factors contribute to the gap between the plan and the resources.
On an agile team we have user stories that are written by a variety of people on the team. There is a template "As a
So in the end there are two alternatives each with their Achilles heal. A coherent professionaly maintained work break down structure that is some what distant to the resources doing the work. Or, a more chaotic structure that the resources doing the work readily understand. Generally I prefer the latter. I'd rather have a looser "plan" with inconsistnecies that people really follow than a really tight comprehensive plan that people doing the work have not internalized or even do not readily understand. In the end it is the outcome of the project that matters. On top of just understanding, there is the ownership issue. By far and away I believe that people work harder when they feel they own the plan and they have personally contributed to its creation. This ownership feeling is fosterd much more when they actually press the keys that make the plan artifact what ever form it happens to take. A perfect plan can never be achieved, however a team fully comitted to a successful out come is much more valuable than a perfect plan. In the end it is the outcome that matters. I'll trade almost every thing to get a team that owns the plan.