Bug Tracking in Project??

[Sarah P.]

Hello! I work for the IT Dept at an insurance company and we are trying to
get a bug tracking software and project management software combined. I
tried FogBugz, but they do not offfer Gantt Charts and that is one of the
major things we are looking for. Does Project offer some kind of bug
tracking option? Or any kind of bridge between the two? Currently we use
Trac (http://trac.edgewall.org/) to do our bug trakcing and nothing for a
project management. Can someone help??

Thank you!!!

 

[Dave]

Hello! I work for the IT Dept at an insurance company and we are trying to
get a bug tracking software and project management software combined. I
tried FogBugz, but they do not offfer Gantt Charts and that is one of the
major things we are looking for. Does Project offer some kind of bug
tracking option? Or any kind of bridge between the two? Currently we use
Trac (http://trac.edgewall.org/) to do our bug trakcing and nothing for a
project management. Can someone help??

Thank you!!!

I think the two things are separate and you should be using two
different pieces of software.

You need bug tracking software to log the bugs and track their impact
against versions of your product.

You need scheduling software to schedule the resources that will be
working on them.

 

[Jim Aksel]

I agree with Dave. Also, consider this...
If a bug is found and documented, you will want to create some type of plan
to close the bug. This includes analysis, root cause determination,
candidate fixes and evaluation, then code, unit test, integration and a fix
file release.

What we've found is that it is very difficult to quantify in work and
duration what it will take to fix a bug. True, a bug is simply a
mini-project inside the bigger one. Many times you spend 200 hours of
analysis just to determine you need to put a check mark in a box to fix the
problem. The tacit assumption is you know what the bug is and the design and
implemation approach to fix it before you lay it into the schedule. I
challenge that baseline assumption.

As such, we treat most bugs as Level Of Effort. We have a bucket of money
devoted to Bug Fixes and a group of resources assigned. Bugs are worked in
accorance with ever changing priorities or until the money runs out.
Sometimes work on Bug#4 is suspended while new bug #15 is worked based on
priority. That is, can we honestly say "Bug #4 is behind schedule" when it
is a low level bug that got bumped by something else. It would be behind
schedule only because the schedule said so.

We establish a bug fix budget based on prior bugs and total manhours over a
specified period of time. That is, the patch must be released on a certain
date and includes all bug fixes completed by that date. This serves as a
"Per Bug" cost and we make some assumptions concerning the fix periods (Total
duration/Number of bugs fixed assuming bugs are worked sequentially -- rarely
the case).

Although scheduling software is useful for this type of tracking, be careful
you are not setting yourself up for a beating.
--
If this post was helpful, please consider rating it.

Jim Aksel, MVP

Check out my blog for more information:
http://www.msprojectblog.com

 

[Sarah P.]

Makes sense. Thank you both for the information, I appreciate it!!