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 : You should manage both. "Project Management" is no more a misnomer than "People Management" is a tautology. The sociological question is: When is change better managed as a project than as a function? The historical analysis is that in many organizations software development was originally managed as a function, then managing as a project came to the fore, and we are now transitioning to managing as a function again. Many of the managers attempting to manage the function still think they are managing a project, however, since that is their personal history. ''When you're project managing building a bridge, you're doing a lot more than managing people. If it's just software you're managing, it may be mostly managing people. But if you're producing a software product, with associated physical products, marketing activities, distribution and so on, then you're back to managing more than people.'' 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 : Still wrong, I think. All management could be said to be ultimately about management of resources. The key question is: Would ProjectManagement be required if all resources were available on demand? My view is that it would, because co-ordination of activities (or 'orchestration of efforts' if you will) is still required. The essential function of ProjectManagement, therefore, is co-ordination of activities; management of resources is ancillary to this. Jeff's turn again ... here's a metaphor: when you go to listen to Mozart's 3rd, does the conductor conduct the instruments, or the musicians? You could say that the symphony corresponds to a project, so it ''is fair to say'' that the conductor is performing ProjectManagement by conducting the symphony. And to some extent he does conduct the symphony (in a live performance) perhaps by working with the mood. But to a much larger extent (especially during rehearsals) the conductor is managing the musicians, not the instruments. Similarly, a Project Manager is not managing the Windows XP, Oracle Server, and Visual Studio sitting in bits and bytes on people's hard disks - those are just the instruments of the developers. : In a very real sense the conductor is conducting the instruments as well as the intrumentalists, sometimes one to the virtual exclusion of the other. More importantly for this analogy, perhaps, is that s/he is reading or knows the score, has researched the history of the piece, listened to other performances, thought about the composer's intentions... and has a vision (or 'audition'?) of what s/he is trying to achieve. ''Back to the bridge building, project management includes being concerned with where the equipment is going to come from, when it is needed, how long the the concrete will need to set, the order of activities and so on. There are people (labor) involved, there are financial/capital resources, but project management still covers more than those.'' 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. ---- CategoryManagement CategoryProjectManagement