Regarding my recent post about cuejecture, (see "King of the Vapor"), I was asked what the differences where between cuejecture and what we're using now (covered in "More Fiddling with Project Management").
Briefly, what we're using now is Plone (slightly modified, including use of reStructuredText), with a custom "Project" portal type. A project is just a Folder that included a special workflow specific to projects so that we can track their state (Pending, Cancelled, In Progress, Suspended, Complete). CMF Collector is being used for issue tracking and to-do management. It's an intentionally simple system - we needed a place that had just enough structure, but wasn't as wild and free form as a Wiki but didn't lay down heavy process requirements.
Cuejecture was intended to be a bit of CRM as much as project management. Adding a new customer to the system added a new special folderish content type, into which one placed Contacts and Projects. Contacts had locations which could in turn contain addresses, allowing contacts to have different (and fairly unstructured) contact information form home, work, travel, etc. One of the intended uses of the system was so that customer contacts could actually be given log-ins to the site to track their projects progress, and may even submit new tasks. A project could be staffed with project managers and team members, and anyone logged in could get quick links to their current projects and open task assignments. This is one feature that I really miss in our current setup, but I may be able to program around it if I ever get the time.
The task system was based on some of Martin Fowler's "Analysis Patterns", based on the patterns in the "plans and actions" section. Tasks could contain tasks, and I believe they could contain "attachments" as well - where one would switch over to the folder view and add extra CMF based content. Tasks were meant to be more light-weight than normal Issues in general bug-tracking system.
So why did it fail? It took a LOT of work to wrestle the CMF into working properly for this type of site. I was thinking "Hmmm, projects, tasks, artifacts, all content - why not use content management?". Comparatively, a co-worker wrote a very simple templates plus SQL based solution over a weekend, whereas I spent months working on this project that was never quite complete.
One thing that core Zope 2 struggles with is being able to manage any sort of non-containment or non-acquired relationship between objects. One thing that we wanted was the ability to generate invoices for customers, and be able to include individual tasks on the invoice and put a time and monetary value with them. To do this properly, we needed a relationship service and event handling service, neither of which exist in core Zope 2. Since writing that project, some community releases have tried to fill in the gap, but at the time I had to focus on writing my own. I want to note that Zope 3 offers these services, and more, that would have made this aspect of development much easier.
This was a project that yearned for a full component architecture, or at least a more business oriented framework. It consisted of many interrelated small objects (the business objects - contacts, projects, tasks, invoices, etc), workflow agents (the workflow agent for tasks was one of the most complex and central parts of the system), services (relationships, events, navigation, alerts), and it could have used an annotation system (a way to add third party data to an object in private namespaces - ie, the invoice could decide to add time and money values to a task). In Zope 2, only the CMF comes closest to providing this. But the basic setup is so focused on "community web site" based content management that it takes a lot of work to disable some of these features. It's doable, but it's still not exactly the best fit for the design I was trying to accomplish. Gods willing, Zope 3 should offer a lot more in this area.