Forum OpenACS Development: Re: dotWRK: Project Manager
Having said that, the key for a project management system is the data model. It has to be abstracted enough so that process can be easily configured by the project manager (or at a higher organizational level) a director or VP.
I would point folks toward the Zachman framework, as a grounding concept for forming a vocabulary around process.
Furthermore, from a software development project management perspective CMM and CMMI could provide a good basis for a general taxonomy around process toolkits. An interesting example could be the RUP web product that focus on a vertical industry methodology as a project management tool. PMI is the place for just project management. It could also be a good resource for vocabulary
I realize this is a little different than the common approach to PM which is to directly dive into the notion of entities like projects, tasks time entries etc or for a more horizontal approach to collaboration.
Certainly these tasks are important but I believe that a successful tool in this area must do a few things well:
1. It must handle hierarchies
2. It must handle ephemeral relationships amongst nested objects
3. It must handle workflow (or object state) and allow for flexible configuration (perhaps creation and definition) of processes.
4. It must capture and allow for analysis, and probabilistic modeling (future planning, risk analysis)
To my first point. Most organization and project management works in terms of an outline. (Winer at userland has gone into outlining tools and there are quite a few that are interesting including ECCO a PIM based on outlining and Mindjet which uses MindMapping metaphor to allow for manipulation of hierarchies)
Secondly, one of the problems with most project tools is that they do not recognize that linking of objects must be easy and follow little structure. ECCO, the best PIM I've seen does. You can take any entry and link it to anything else. It is loose but provides excellent context. This establishment of object relationships should be very flexible, the way thinking is, and then the tool should allow for cleanup and after the fact organization. PM tools are really bad at this. But a great tool at this is something like Request Tracker, the open source trouble ticket system (which also has neat e-mail integration).
One of the ways RT is excellent is that you can imagine a project having 5 ticket cues. One for Idea Stage, One for reqs , one designed, one in built, one in test. A ticket could travel amongst the queues based on some type of user defined promotion criteria. A ticket could be split or tickets could be rolled up, and a history would allow for temporal context of the ticket life.
I think ECCO would be a great starting point for understanding functionality for a project management tool From a single user perspective. I think RT would be a great place to understand lifecycle and workflow (as well as integration with e-mail)
I have to do some thinking on the analysis part.
Ivan
Do you have links to any of the products you've described?
Unfortunately, I've already started work on the project-manager, so a lot of the data model has already been completed. It is open to being changed, however.
I strongly agree with you that flexible hierarchies are extremely important. I'm trying to build this into project-manager, but I'd appreciate any insight into ways this could be improved.
Right now, I'm trying to get as much accomplished on this as possible by the end of August. So although my focus before now was on collecting information, right now, I'm focused on writing it.
However, I do want to make sure we're on the right track, and I'd welcome your help in whatever form you're able to give it.
---
If you or anyone else is interested in keeping abreast of what's happening with the project manager, you can get email notifications on the project-manager to-do items and bugs from the bug-tracker:
https://openacs.org/bugtracker/openacs/com/project-manager/
The current implementation of project-manager has a hierarchy both of projects and tasks, to arbitrary levels.
So tasks can be easily broken down into subtasks, and projects into subprojects. I aim to make it easy to move this hierarchy around, and see how it works.
The project-manager is built on the content repository, so it allows symlinks between objects (such as the tasks and projects), so potentially, a task could be part of multiple projects, for example. This may provide the interface you're describing, although I'm not familiar with the products you describe.
The trick is mostly going to be in the UI. Designing scalable interfaces for complex hierarchies, with thousands of projects and thousands of tasks is the challenge.
