Bryan, RT (3.x ) is an issue tracking tool, not a Project Management tool. There are no built-in charts and reports for such, as RT lets you devise your own. There are many Project Management (PM) and Portfolio Project Management (PPM) tools out there, they cost a bit of money to either use their system (SaaS/OnDemand) or to get their software installed "in house". I believe Project.Net is "open-source" so they would be a good pick for a total PPM package. @Task is a good one (PPM), but it costs. The PPM software available is also broken up by orientation (ie. IT PPM or Business PPM, etc.). I believe that RT 4.x is headed in that direction. Hopefully, it will be a good competitive product with Project.net & @TASK. From what I've seen of RT, I think it will.
However, using the RT version we have available, many things will need to be added by you. First, you need to have an idea of what your infrastructure will be. You need to have a WorkFlow process in place for Reviewing & approving a ticket initially, the development done for a ticket, and the QA aproval process. This is important because all your work, new Queues, Groups, what work will be in what Queues, what groups have rights to what work/Queues, etc. will be based on that infrastructure/Workflow rules. The scrips you write, both for notifications and for added functionality (like pre-setting ticket owners based on a Custom Field value OR automatically changing the status of a ticket because a ticket was "QA approvd", like resolving a ticket does) will all require consistency within that agreed-upon infrastructure. Even the names you give Queues and groups should have a consistency/convention that gives some structure to the whole thing. Once this is done, you will be able to decide what Queues to create, groups of users, rights, what Custom Fields to create for which Queues and how they will be used for ticket processing. The Parent/Child/DependsOn Links that RT allows will easily fit into a simple Query, but trying to get all the due dates of each Parent/Child/DependsOn relationship will require a bit more complicated SQL than you will get with RT Query. So, until you have the infrastructure and workflow processes and naming conventions worked out, it would be hard suggest what you asked for. I hope I didn't go too far in answering your question.;-). Kenn LBNL On 7/23/2009 12:00 PM, Bryan Ellinger wrote: > All, > > I would like to get started using RT for PM of a hardware, software > integration project. There has been talk on this list about > using RT for project management. However, I have not read much about how > others are doing it. > For instance, what is the most sensible way to set up queues? It seems like > it might be good to give each group, e.g. SW > engineering, HW engineering, Applications Engineering etc., their own queue. > But how would one determine which tickets belong to > which of many possible projects? Should each project have it's own queue > instead? > Anyone care to share how they apply RT to their general PM processes? It > would be a big help to me. > > Sincerely, > Bryan > > Bryan D. Ellinger <[email protected]> > Applications Engineer > Applied Dynamics International > 3800 Stone School Road > Ann Arbor, MI 48108 > 734.973.1300 ext. 289 > 734.668.0012 Fax > http://www.adi.com, mailto:[email protected] > > > > > _______________________________________________ > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users > > Community help: http://wiki.bestpractical.com > Commercial support: [email protected] > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > Buy a copy at http://rtbook.bestpractical.com > > _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [email protected] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
