Re-Open Task (Workflow Question)

[Leon Milbeck]

2007 MS Project/MS PWA
Presently we use MS Project to track bugs/issues for specific Service Packs
of our software.
We create the project name based on the version format
(Major.Minor.Service Pack.Build)

Happy Path:
1. An issue is created in JIRA (issue tracking system)
2. PM assigns task to Developer (Name, Est. Duration, Resource, Notes).
3. Work is done.
4. Developer closes issue through PWA.
5. PM updates project.
6. Task is now complete (100%)

Workflow question:
7. Issue is sent to Software QA and found to not be fixed.
8. Issue is re-opened in JIRA

Should I create a new task in Project for this or adjust the previous entry?
Definitely affects the way we do reports depending on the way I choose.

Just wondering how other PM's do it ...

Thanks,
Leon Milbeck

 

[Jim Aksel]

This can get complex as I am sure you have imagined. The difficulty is
determining the amount of work it will really take to correct a bug.
Ordinarily, all of our bug fixes are Level of Effort tasks, not specifically
identified by number.

There have been a few occasions where we specifically identified a bug by
number and established a budget and schedule to get it fixed. In effect, it
became just another function point to deliver. Once that bug fix made it
through unit test we allowed the developers to claim 100% against that task.
If QA found (additional) trouble with the fix, we pushed that off to a Level
of Effort bucket and it just got prioritized in the queue.

It seems the direct answer to your question is to create a new task.

The other method is to allow the first task to claim 80% Earned Value when
it passes unit testing. They are allowed to claim the remaining 20% once the
item is released from QA. If QA finds (more) bugs, you extend the
development task and add more work. The problem we have had here is the way
it drives schedule logic. Technically, you are allowing QA to start before
the predecessor is 100% complete which somewhat violates the logic of the
game. However, we all do it all the time. So, in this scenario, you allow
both the development task and the QA task to extend.

You will have to decide which is better for you. We find that sooner or
later we are going to let a bug ride into the release if it is not a major
problem (we all do this for minor bugs all the time). Doing it the first way
I described allows us to claim 100% and move towards the release while we
track the bug as Level of Effort separately. This way we can needle the
developers and only give them so much budget for bug fixes. If they get too
"buggy" they have to come back to the PM for another dip in the money well
for their LOE.

---
If this post was helpful, please consider rating it.

Jim Aksel, MVP

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

 

[Jack Dahlgren MVP]

I would create a new task which shares the same JIRA id.
You could re-open it but I think that method would be more trouble and would
not capture the fact that the task was re-opened.
Using separate tasks for each re-opening would tell you that you are having
issues with getting things right the first time so it gives useful
actionable information.

-Jack

 

[Leon Milbeck]

That is the route that I plan to take. Thanks to all for the help. It would
be nice if Project Server was more Agile based on not so Water-fall centric.
In our hectic fast-paced-get-it-out-the-door-now world things don't just open
and close and stay closed.

Thanks again,
Leon Milbeck