A few days ago I explained why a project - if it's going to be the fundamental unit of analysis of human activity - needs to be conceptualized in terms not only of collaboration but also of differentiation. And why we need to think of a project not simply as arising from a contradiction, but as arising from a human need. I can now add a few more points to that starting place.
I've said that a project is a response to a human need, and that it has as its product something tangible that can satisfy that need. A project is a transformation of the material circumstances, physical, biological and social, in order to satisfy a need. That transformation is accomplished through human ingenuity, both skillful action and cognition-in-action. I agree with Andy to the extent that he is trying to link thinking to action, theory to practice. But that's been done before - in, for example, Heidegger's account of the different modes of engagement (ready-to-hand, unready-to-hand, and present-at-hand), all of which are structured by thrown-projection. So let's stipulate that it takes intelligence to transform the world, and a project employs (and extends) human intelligence.
That means that we can take what we already know about physical and biological reality to help us understand our own social reality (that is, we too are engaged in a project, transforming the state of our understanding of human activity). The physical and the biological provide constitutive conditions for human projects. Because there are regularities in the physical world (e.g., the earth spins on its axis) and biological organisms are adapted to these regularities (e.g. cycles of activity and sleep), human needs recur (e.g. I want to eat breakfast every morning). When we define projects as responses to human needs, we can see that because human needs are cyclical projects will often become routine.
I don't think Andy's definition of 'project' handles routines very well. It seems to work better with activities like the strike that Brecht is studying. A strike is a newsworthy event, with explicit demands. But most projects are not so eventful, or so explicit in their ends. However, under my definition a routine is also a project. Or, to put it the other way around, a project often becomes routine, because it needs to be repeated. A routine is about meeting needs through repeated transformation of the world. Bread must be baked fresh each morning and sold each day. The crops have to be planted every spring, not just this year.
This is important, because when a project becomes routine it acquires a normative character, which can develop into explicit rules. And when a project becomes routine its differentiation can become a division of labor. Or it can become playful competition. Or it can become a conflict. Or the division of labor can become exploitation. Each of these is a qualitatively distinct combination of collaboration and differentiation. Also, because of its differentiation every project will require specific social relations. When the project becomes routine these will become recognized *kinds* of relations, which can define recognized positions, or explicit roles, and identities.
In this way, through necessary repetition, a project becomes routinized, objectified and institutionalized. It will define the positions, resources, and identities from which and with which people can take up a new project. A project doesn't start from nothing and nowhere: it starts from a need and a concrete circumstance, but both these will usually be products of previous projects. History accumulates. New projects emerge within and among the routinized and objectified forms of prior projects. This will both constrain them and enable them. People involved in a new project may find that there is simply no room for it alongside existing projects. Or, they may find that the existing projects facilitate and provide the raw materials (not now so raw) for their new project.
And, as Lubomir pointed out, humans are sociospatial organisms. The next step is to explore how that fact establishes conditions for projects....
Martin
__________________________________________
_____
xmca mailing list
xmca@weber.ucsd.edu
http://dss.ucsd.edu/mailman/listinfo/xmca