Issue Tracking System?

[hygear]

I wanted to find out what everyone is using to track engineering issues? My company has a central office located in another country with a very nice issue tracking system, but for whatever reason they want the regional development office (where I am located) to use their own tracking system. Because of this, each of our local engineers have come up with their own way of tracking issues. This has led to manufacturing/field issues slipping through the cracks, and closed issues that others have no way of reviewing.

At my previous job we used a modified version of the Bugzilla software to create and track issue numbers and then stored all supporting documents on a file server under that issue number. This system was wonderful because issues could be prioritized and it could send out weekly e-mail reminders about issues that nobody was working on. It also made searching for a particular issue very easy because we could do a keyword search in Bugzilla or an index search on the file server for supporting documents.

Unfortunately we don't have the resources to setup something like Bugzilla at my current job so I am looking for ideas on implementing something that is simple but functional. One major requirement is that we want to avoid using an Excel spreadsheet because we have had too many issues in the past with files getting locked or overwritten.

 

[MiketheEngineer]

DUH - why not use the same one the home office has?? Seems cheaper and easier to install and train?????

 

[IRstuff]

?? Bugzilla is free, isn't it?

TTFN
faq731-376

 

[drawoh]

hygear,

Many years ago, I set up a document control system on a UNIX file network using C[ ]shell scripts and Change Requests (CRs) entered in ASCII text.

It was easy to do keyword searches for the text files for document numbers and keywords. I had separate directories for current CRs and for closed CRs. That way, I could focus on the issues that had no been resolved yet.

Obviously, if a document is listed by an active CR, you have to read the CR and find out what the problem is, before you use the document.

--
JHG

 

[LiteYear]

I second MiketheEngineer's suggestion. It seems to match your requirements - low setup/training requirements and avoids yet another system to deal/interoperate with.

Failing that, Bugzilla is about as low overhead as you're going to get - unfortunately these systems are only as valuable as you make them. If there's no resources to support the system, any system will eventually fail. This point is often missed for some reason.

Finally, to answer your question, we use JIRA here because of my recommendation. Seemed to be a good compromise between flexibility and amount of necessary configuration. Works well for us, but at the end of the day it's just a tool - how valuable it is comes down to two things: how well it is maintained and how well we integrate it into our work procedures.

Come to think of it, JIRA also has hosted options. Hosted/cloud/on demand style systems might be worth a look if you want minimum setup/maintenance overhead. Of course you pay for the privilege.

 

[truckandbus]

We used to use excel spreadsheets but they only work if someone rides herd over them. Eventually our IT guys wrote a program for our AS400 that provided email notifications and tracking. The single thing that makes any system work is discipline. None of our engineers will look at a problem unless it comes out of the system - that way they know the asic checks and investigations have been done.

When I looked into this years ago, I found several 'help desk' applications that were web based that looked like they could handle typical production and customer issues.

 

[ScottyUK]

It always amuses me when people insist on trying to make a spreadsheet to perform the work of a database. One careless application of a sort operation and your data is in a real mess.

Have a look at Access. The wizards make a passable attempt at building your database if you know nothing about databases, there are loads of ideas and examples on the net to learn from, and if you are willing to learn a bit of VBA you can tailor the behaviour your database to your needs.

 

[hygear]

Just to clarify on a few of the issues that people have commented on:

1. Why not use the same system as the home office?
It is in Japanese and would be extremely expensive to translate to English (~$2 million from what I've heard).

2. Why not use Bugzilla?
Bugzilla worked at my previous job because engineering had their own server and I was in charge of it. At my current job we don't have the (engineering) budget to buy and maintain a server and IT won't allow us to install software on any of their servers. The other issue is that it is against company policy to use opensource or freeware software.

I know that we need to get a real database system but I'm not sure that Access would be the answer since we need to attach large amounts of data (pictures, test data, drawings, charts, etc.). My fear is that Access would get bloated and start causing us more problems than it fixes.

 

[FreddyNurk]

I'm somewhat amazed that a company has a policy not to use open source software. I've been gently suggesting BugZilla for a little while, but I've not pushed the notion that much, though the current solution of using Sharepoint isn't that nice either. I did push for SubVersion a while ago, and its been brilliant for what we need.

Access, whilst somewhat useful as a Database (and far far better at running queries on data than Excel is), is soon dwarfed by the capabilities of other SQL solutions (say, PostGreSQL or MySQL, Oracle and licencing conditions notwithstanding). I completely understand the roadblock of IT though.

 

[truckandbus]

sounds like your hands are tied by the IT policies. Maybe IT needs to provide the solution...

Non-software solutions I've used:

1) One person as designated point of entry into the engineering department for issues - ensures only one person works an issue; hopefully can remember duplicate or similar issues; makes sure relevent documents/checks have been made to make resolving issue easier

2) White board (either physical or virtual) that can be seen/accessed by all engineers where each person writes a brief description of the issues they are working. Particularly useful if you are working across shifts; prevents more than one engineer from working an issue.

 

[LiteYear]

Ah bugger, web browser ate my home work. Here's what I said, massively compressed:

Now I start to understand your environment and your predicament! Here's what I'd do:

1) Start your own IT network. Use an old PC as the server, buy equipment using unrelated budgets, spend a weekend installing/maintaining. Sounds unrealistic but in my experience it works and save so much pain! If you want a new Subversion repository - done. If you want to try a new issue tracking system - done. If you want a file sharing repository - done. I'm very familiar with these no opensource policies and just can't stand it. We (the engineering department) like using the right tool for the job and then getting on with the job. We cannot rely on IT to provide that environment for us.

2) If (1) is not feasible, then that's what god invented the cloud for. Use managed/internet/cloud services. There's trade-offs, but at least you'll be able to use the right tools.

 

[GregLocock]

"the current solution of using Sharepoint isn't that nice either"

I share your pain

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[HDS]

hygear how are you using a web browser? Did you find one you could buy? Sorry...

Try Asana or RT both have free and paid options since you have to buy something. There is probably someone that will run bugliza on a server for a fee.

http://asana.com

http://www.bestpractical.com/services/hosting.html