All of the project management software I have used or evaluated provides two structural elements, which I’ll call “projects” and “tasks.” A project collects one or more tasks into a block of time. Furthermore, all of these applications assume that
- The project can be decomposed into discrete chunks that can be started and finished within a discrete block of time. Perhaps the length of time can be flexible, but still, once started the tasks grind inexorably to their finish date, never to be revisited.
- Since each task “starts” and “stops,” tasks that repeat are very difficult to track appropriately.
- The project development can be described using a tree data structure.
As I write this, I realize it’s not quite true. The breakdown is actually time based versus activity based, and what I just described above is activity based.
The conundrum is that the activity-based systems don’t formalize the notion of identical intermittent activities (such as debugging) within the project/task structure, while the time-based systems really have a task/activity structure.
Reconciling these two architectures is not possible without introducing some cross-cutting. For example, activity-based systems need formal definition of activities that can be listed under more than one branch of the tree. That is, activities should be listed corresponding to relevant tasks, and occupy the appropriate amount of time. This would allow time budgeting for activities such as refactoring, debugging, and administrative overhead to be incorporated at the “Task” level.
