Additional Project Fields

We recently received the following feature request:

The project functionality offers limited options to categorize it. I am looking some additional fields to populate data such as Project Sponsor, Project contact name, project complexity (high, medium, low), project type (new enhancement, new development, maintenance, support, admin)--it should be a user-defined field like the Module field but attached to the project. In addition, I would like to see a field for project class (Strategic, Non-strategic, capital intensive, business as usual).

Intervals currently does not have a lot of project specific fields to try and keep creating new projects quick and easy. The project description field is the catch all for any supplemental project related information, but that information cannot be sorted or used for reporting.

I'm curious to get thoughts on this from others. Too much complexity? Would this benefit you or add too much?

We would also like the ability to better categorize projects at the project level; User-defined similar to modules within tasks. Two such categories would be great, e.g. Project Type and Project Class, or some such thing.

The primary reason we were interested in these (two) additional project categorization features was to provide grouping capabilities in the back-end reporting. For the time being we have gotten around this limitation in the instances we needed it by defining additional duplicate clients and insome instances additional duplicate projects. (We are also already using modules for further business department type breakdown.)

As an example, some of our client definitions are defined as "Client 1 - New Development", "Client 1 - Prod Support", "Client 2 - New Development", "Client 2 - Prod Support", etc. We can then easily report on all of Client 1's New Development activities across all areas by simply reporting on this one "Client 1 - New Development" client. Likewise for Client 1's Production Support activities by reporting on the "Client 1 - Prod Support" client.

Similarly, in some cases it was more efficient for internal activities to duplicate projects rather than clients. For example, "ERP - Prod Support", "ERP - New Development", "ERP - Initiatives", "Web Services - Prod Support", Web Services - New Development", "Web Services - Initiatives", etc. This isn't always quite as convenient when needing consolidated reporting because we need to select multiple entities in the filter, but we try to do this once for each and save the report filters. For example, when we want to report on all internal "ERP" project activities we simply select via filter all of the projects prefixed "ERP". Likewise to report all internal "New Development" project activities we filter via filter all of the projects suffixed "New Deveopment".

This isn't a particularly glamorous solution, but since we were dealing with a limited number of combinations we needed to break out it works quite nicely for us. I would appreciate hearing from others who may have applied another type of solution to accomplish a similar reporting need.