Project ecology

It’s standard to describe software development and implementation projects as having “life cycles.” If you look at some of the cool new agile tools, you’ll see another paradigm: story-telling, in which a project becomes a narrative, and each task is expressed as an episode in the imagined worklife of the end user.

I’d like to suggest a different metaphor, project ecology. After all, when we work on a project, we are connected to one another in a variety of ways. For example, if we are building a web interface together, imagine that you give me a spreadsheet with an analysis of the components I’ll need to understand a key requirement. Several of our colleagues gave you the information you needed in order to assemble the spreadsheet. And, once I’ve digested what you’ve given me, I will write up a specification and then give it to another colleague who will add this information to the design for the prototype.

We are connected by the information exchanges, by the tangible inputs and outputs (the deliverables) we pass along, and by our personal relationships. What if we who work on projects together viewed all these interdependencies as an “ecology” of sorts? How might this change the way we relate to one another and to the project?

If you follow this way of thinking, the person who is building the prototype, who is waiting for my specification, is, in effect “down river” from me. If I am able to perform my work “cleanly,” that is to say, in a timely fashion and leaving few unanswered questions or–at least–undocumented issues, then the momentum of the project moves through my part of the “ecosystem” unencumbered. My downriver colleague gets a fresh start on her tasks, and the project is not building up an inappropriate backlog.

Of course, new and unforeseen problems do arise during projects, just like dangerous rocks are often just below the surface of a river. If the problem occurs on my watch, it’s up to me to make the first response to it, one way or another. In other words, if I am going to pass along a problem, I want to be able to present a problem statement, explain my analysis and offer my understanding of the best next steps.

It’s a simple idea, that boils down to this: no dumping. What do you think?