This post originated from an RSS feed registered with Agile Buzz
by Laurent Bossavit.
Original Post: What is a project ? (II)
Feed Title: Incipient(thoughts)
Feed URL: http://bossavit.com/thoughts/index.rdf
Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different.
In a recent Usenet thread on "The Essence of XP", the following definition of "project" came up in response to a remark on "how XP does project management", prefacing a tirade about what "real" project management in fact is:
Project : a temporary endeavor undertaken to create a unique product or service. 'Temporary' means there is a definite beginning and a definite end.
This definition would seem to exclude many efforts that I have heard described as "projects". Some projects are not temporary, but ongoing; for instance, the "Open Directory Project". Many projects are undertaken to do something that is very, very far from unique; for instance, we hear about "hardware rollout projects". Projects often lack a definite beginning, since the line between an idea and a project is often a fuzzy one. Projects more typically have a definite end, but this end often turns out not to have been the one envisioned when the project "started".
People are asked to formulate their "career project", and the like. (Interestingly this varies across cultures - I turn up a far greater number of phrases of this sort in French than in English, where the equivalent seems to be "plan".) We talk about research projects - which cannot have defined outcomes, but only defined angles of inquiry. "Project" is the term solution vendors use when they want to know when we intend to buy whatever they peddle: "What is your project timeframe" is a stock question in product information forms. Our societies have a project fetish, as French psychologist Jean-Pierre Boutinet suggests in "Anthropologie du Projet".
In sum, "project" is a particularly overloaded term. I am beginning to wonder whether the debate that has resulted in the crystallization of the "agile community", so-called, might have its roots in a territorial conflict over the "idea space" delineated by the term. People are coming to the software field with wildly different understandings of what "project" means - none of which has a serious claim to be truer than the others - and projecting these conflicting prejudices onto the various activities involved in creating software.
We would do well to step back from the contested space that the term "project" covers. This would also involve stepping back from the ground staked by the terms "agile" and "classical".
Having stepped back, we might more serenely review what we want from various kind of efforts involving the creation of software; which outcomes of these activities we value (the advancement of a discipline with a short history, the economic contribution of software-producing businesses to society, the individual learning which occurs in such efforts, etc.), which outcomes should be avoided (the pressuring and humiliation of workers in the field under unrealistic deadlines, etc.), and which practices are more effective in furthering these aims.