At my office, we are currently working on a project from the PMO office that encapsulates multiple products. In many ways, conceptually it would essentially be equivalent to a CounterSoft project that would result in Gemini 3.7, Data Import Tool x.x, Scheduler x.x, etc. Additionally, this project will be done in an iterative fashion (RUP instead of Agile).

There are several issues/questions (along with our solutions to this point) that I'd like to present for discussion. We would like to improve our processes where ever possible. Our goal is to utilize Gemini to track issues at the project level, at each impacted product level, and assessment tracking (test plans/cases). At the moment, we do realize that [url="http://gemini.countersoft.com/issue/ViewIssue.aspx?id=477&PROJID=2"]test plan/case management is scheduled for the 3.7 release of Gemini[/url].

At the project level, we are currently tracking Business Requirements, Business Risks, Technical Risks, and Project Change Requests (all as issue types). User/Software Requirements (use cases) are tracked at the (appropriate) product level as New Features. To accomplish this in our installation of Gemini, we have a Gemini project for each of our products. We also have a Gemini project for the PMO project itself. It has project evolutions/stages (not phases) as its components and iterations are tracked as versions. New Features are sub-issues to the appropriate Business Requirements (cross project link).

For those unfamiliar with an Iterative Development Process, every iteration results in at least one software release. When multiple products are involved, more than one software release can occur. This, combined with the separation of product and PMO projects in Gemini, present significant issues in trying to produce plans (or Road Maps) at the project level. Essentially, we are attempting to connect one version (PMO iteration) in one project (the controller or PMO project) to versions in other projects (actual product versions).

Today, we are accomplishing that by examining issue linkage (normal linkage or via a sub-issue relationship) in custom SQL reports. Unfortunately, that's a little difficult and clunky. I'm considering a naming standard with the Version Name field between the projects, but I'm open to other options. I'm not especially fond of this given Gemini's usage of Version Name instead of Version Number on filter/summary/road map/change log screens.

If you're still reading...

I'd love some feedback on how we are choosing to implement Gemini for our needs (pros, cons, recommendations, etc.). I'd also like to hear from those that are attempting to utilize Gemini in a similar manner.

All feedback is very much appreciated.

Thank you.

David Singeton Application Development Manager Tennessee Treasury Department