[tlester]

Hi all -

I'm a combination software architect and group lead for our software tools that my IT Operations division uses. I have several applications that I own. I architected them, managed the development, etc. I have several others that I didn't directly create/architect, but I "own".

Basically anything related to our software tools (architecture, resourcing, RFE's, bugs, integration, etc) falls in my realm.

So... here's what I need advice on. I have several things that I need to track very well. For example:

- New development projects. This is the easiest, I think. This is, "we need a tools to do X" and I design a new tool, write and the architect docs, specs, hire the developers, etc. This seems logical to make a project. So, a project for each tool being developed.

- Request For Enhancements (RFE's) for existing tools. This may be a tool that was first a project like listed above, or may be a tools that's supported by a different team or 3rd party, but I'm in charge of gathering, writing, and delivering RFE's.

- Bugs. Similar to the RFE's, but I have to track bugs that crop up against my apps or 3rd party apps. I have to make sure I follow these through to resolution. This means a lot of items here will eventually spend a lot of time in some sort of "waiting for" context.

In all these cases, I'm going to have a lot of need to review with my team, gather requirements from my team and others, meetings with developers, meetings with my staff, etc.

What would be best practices for building a good way of tracking all this? Do I track bugs under the project or do I have a separate project for bugs? How about RFE's?

Curious.

Thanks,
Thomas