From the XpMailingList:
TheFundamentalProjectManagementQuestion is: we're halfway through, are we halfway done? -- KentBeck
Eh, probably not. It's the old EightyTwentyRule... the last 20 percent of the project is 80 percent of the work.
If the last 20 percent takes 80 percent of work, then it makes business sense to cut the project down, if the work done to date is acceptable. Even if an IT person does not agree to this 'lack of professionalism', lots of good explanations has to be given to the users, and accountants. -- dl
Another all-to-common metric is that the first 90% of the project takes the first 90% of the budget and the last 10% of the project takes the other 90% of the budget!
The fundamental question is: if we have twelve things to do and twelve people to do them do we give each person one thing? -- WardCunningham
The answer is no, no, no, but we understand how hard it is to do otherwise. The problem with dividing up the work is that it also divides up the group and thus prevents collaboration.
The answer is: ItDepends . Sometime it makes sense, sometimes it doesn't. (I think the original question that started this page is a better fundamental one)
I've always argued that you don't manage projects, you manage people. Hence Project Management is a bit of a misnomer and reflects a sociological error in understanding. Yes, we are paid at work to get things done, but managers need to understand that the SociologyOfWork is more important in the long run. -- JeffChapman
Let me help explain Jeff's point by saying that ultimately ProjectManagement is about management of resources. In financial terms these are broadly classified as capital and labor. The point is all resources are managed through a person, or group of persons. Project managers therefore aim to excel in the orchestration of efforts by all stakeholders (people). -- dl
Well, I stand enlightened (Jeff again); a sincere thanks to the text-indented contributor who pointed about the extension to the Conductor analogy ... especially the part about having a vision of what they are trying to achieve. So now I wonder if I can phrase a different case of TheFundamentalProjectManagementQuestion: are the benefits of managing to my vision worth the costs (risks) to the SociologyOfWork? To reuse the analogy, is it okay for the conductor to be an overly demanding asshole and make nearly unreasonable, demeaning, and harmful requests of the musicians to the benefit of the performance? Who determines the tradeoffs between benefits of morale versus accomplishments of the project? Also see Donald's paragraph in the section below which takes a larger, more holistic viewpoint.
See also: SharedVision
In a functional as opposed to a dysfunctional definition, Management is a question of shaping the future. The future of an organization or entity is dependent upon its success in shaping a future which provides success for both projects and people. The most successful managers will achieve both the completion of reasonable and practical projects, but also the preservation of FabricOfAchievement? which identifies the needs and contributions of those employed in that completion. While achieving, a manager with FutureSpectacles? on, will be developing future opportunities for further achievement when the present opportunity has resulted in a success. Without such foresight, the manager and the managed will be only be temporary resources employed by the ArtificialEntity?. -- DonaldNoyes
I thought the fundamental question was When did Managing the Project become more important than Delivering the Product?.
This is probably because I have a jaded view of a few project managers who were so insistent on following the rules and producing the documentation that they missed the fundamental point that these activities were precisely why the development team's productivity was decreasing. Rather than let the developers get on and do what they do best they were buried under the requirements to produce documents to support the project.
I concur with the fundamental question proposed here. I would also suggest there is a strong tie into WhyIsDomainKnowledgeNotValued. When software becomes viewed as an exercise in scheduling and resource management rather than a support task for business functions, we run into the above situation.