Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Should a team of system administrators who are on a software development project share a project management tool with the developers or use their own separate one?

We use Trac and I see the benefit in sharing since inter-team tasks can be maintained by a single system where there may be cross-over or misfiled bugs (e.g. an apparent bug which turns out to be a server configuration issue or a development cycle which needs a server to be configured before it can start)

However sharing could be difficult since many system administration tasks don't coincide with a single development milestone if at all.

So should a system administration team use a separate PM Tool or share the same one with the developers? If they should share, then how?

share

migration rejected from stackoverflow.com Feb 21 at 21:47

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by gnat, Dan Pichelman, MichaelT, amon, DougM Feb 21 at 21:47

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
Should chefs share a kitchen? –  Chris Jun 3 '11 at 1:30
2  
Depends if they are cooking the same meal for the same patrons –  David Jun 16 '11 at 6:35
comments disabled on deleted / locked posts

4 Answers

up vote 1 down vote accepted

It really depends on how often cross-over occurs, how large the teams are, and the style of development that you follow. For instance, a development team using some variant of agile programming will probably not coincide well with IT, which tends to have more more of a focus on day-to-day tasks combined with much longer term projects (e.g. how are we going to support the projected influx of employees at our startup?).

If there's a significant amount of cross-over and the developers need high visibility into how quickly IT is planning to accomplish something, it would make sense to give IT its own project within the same overall bug tracking tool. That way, everyone maintains visibility but there's still a degree of separation so IT can track its own milestones and the development teams can do the same. You might even consider a specific project dedicated solely to crossover tasks.

On the other hand, if there's not a significant amount of cross-over it doesn't matter much how you do it. Tasks can be handled on a case by case basis. However, the fact that you're asking this question would indicate that it happens more often for you.

Separate projects in the same overall software system is the way I would handle this. If Trac isn't flexible enough to allow you to do that in a way that makes sense, you should consider switching to a different project management tool.

share
add comment

I pushed for hard for a single system for a couple of projects where we had three different development teams working on separate but integrated systems. It worked ok for that.

In some of our very large enterprise changes (such as acquisitions) the project team will get an executive to force hundreds of disparate application teams sharing nothing other than a cost center to use a single defect tracking tool so he can get a dashboard report. Everyone grinds their teeth and pays a contractor to do the dual entry so the individual project teams can live in the their own little worlds.

Pros:

  1. Easy to get a composite view of milestones, tasks and issues
  2. Do not have to do "double entry" if a bug needs to be assigned to another group

Cons:

  1. Workflows & conventions may already exist and be different for different groups
  2. Groups may have all their projects in another repository, don't want to log into multiple PM/bug tracking system if they work on multiple projects

    • This assumes a matrixed org in which you have separate groups of functional specialists who work on a partially over-lapping set of projects, which is very common in large companies.
share
add comment

You should use what works best in your environment. We have separate systems for IT and for the SW developers, simply because there is little overlap, and if the engineers need something from IT, they simply raise a ticket on the IT helpdesk, it gets seen to and that's it.

Having said this, within SW Engineering everybody uses the same bug tracker, even though there are big teams working on seemingly unconnected projects. And that works well for them, too.

So there really is no hard and fast rule. Try one thing, monitor how well it goes, and then adjust.

share
add comment

We use multiple systems and IT has their own and access to what is used for product development. Essentially, if something requires IT support (like web server configuration), it can be assigned and dealt with appropriately. The other system is used for things like employee desktop support and their own projects.

In the end, while it may be nice to have everything in one system, the various departments should use the tool that suits their operations and processes the best.

share
add comment

protected by GlenH7 Feb 20 at 14:56

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.