<< ALL BLOG POSTS

In Search of a Better Project Management Tool

|
April 29, 2011
|
Table of Contents

At Six Feet Up, we have been using the web-based project management software Trac since 2005. It has been a great tool for managing tickets and specifications. As the company has grown, so has the scope of our project management tool. We have customized Trac to meet our needs through configuration tweaks, third-party plugins and even a few in-house plugins. We are getting close to reaching the limits of what Trac can do for us.

What Got Us Here?

The biggest issue with deploying Trac for multiple projects is the fact that each instance is its own island. The only built-in feature to integrate each instance is the intertrac syntax, but this only allows you to easily link to tickets and wiki pages in the other instances.

We have a lot of data that is not easily searchable, so this is a big drawback for us. The other big drawback is the way that Trac is configured. The project managers have to get a sysadmin to make changes to certain aspects of the system which should be configurable through the web.

Where to go from here?

Seeing that we were rapidly outgrowing Trac, we started looking at alternatives. One of the best open source options we have seen is Redmine, a project management tool built on top of Ruby On Rails. For our Third FedEx day, David Blewett and I took a deeper look at Redmine to see if we could migrate our existing Trac instances to it.

Redmine Pros

Redmine has some very interesting features that make it very appealing to us, including:

  • Support for multiple projects in one instance. Also supports sub-projects so that a single client can have multiple projects all grouped together.
  • The idea of having nested items is also carried into the issue tracker. Tasks can have sub-tasks added to them.
  • The web interface gives an administrator the ability to manage almost all of the settings for the application. This is a huge improvement over Trac.
  • Another really big feature is the ability to save queries. In Trac, you can create reports, but this feature just seems tacked on.
  • Built-in support for ticket relations. You can link a ticket by saying that it blocks, duplicates, relates to or precedes another ticket. We use the TracMasterTickets plugin to support this in Trac, but it is not as well-integrated in the system.
  • Redmine's workflow states allow you to set any state as "closed". In our process, this is important since we keep tickets alive after they have been tested in order to know when to do a staging or production release.
  • Redmine has a pluggable text formatting system. This means we can use multi markdown as the default text format.
  • Redmine has some nice add-on themes that have been developed for it and looks to have a saner way to make changes to the interface.
  • There is a Trac migration script included with the app.

Redmine Cons

While preparing to migrate our data into Redmine, we were seeing if we could configure it to behave in a similar way to Trac. There were some things that we didn't like and a few blockers to our immediate use:

  • Redmine is written in Ruby, but our expertise is in Python. Writing add-ons won't be as easy for us in-house.
  • One of the pros for Redmine was the ability to manage different types of fields via the web interface. The problem is that you can't define one list field and have each project have different values for it.
  • The workflow does not support tying an action to a workflow change. In our Trac workflow, when you are done with a ticket, you click one button and the state and owner are changed for you.
  • The multi-ticket editing in Redmine only allows you to make a change to one field at a time. The batch modify plugin we use in Trac allows us to change several fields on a group of tickets at once.
  • The relations support in Redmine is nice, but there is no way to see the relations in the issue listings or Gantt charts.
  • To follow the item above, there is no Graphviz support for dependencies.
  • With no way to visualize the dependency links, we are forced to look at each ticket to see if there are blockers to completion. This is a big step backward for us.
  • We had some issues getting the app running. There were Rails and gem version issues that required us to modify some source code to get the rake tasks to work. While not a huge issue, it did set us back a bit.
  • The migration script is really meant for an unmodified Trac instance. For us, we will have to do some extra-curricular migration work to get all of our data into Redmine.

Conclusion

We didn't complete our FedEx day project, but we gathered the information we needed. Once we hit the blocker issues, we looked around at some other options. Most of the open source tools seem rather incomplete compared to Redmine or Trac. One other option would be a paid application like Jira. We watched a video of Jira in action and it certainly looks very nice. But the costs involved are too high. We would be better served to invest the money in improving an existing tool like Redmine.

We still think that Redmine can be our next generation project management tool with a little bit of effort.

Related Posts
How can we assist you?
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.