1 to 5 of 5
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).
Project contact name isn't that already the client? I have asked in the past that intervals include multiple contacts under one client. This could improve employee recoginition, and reduce the number of clients added from the same company. So I could see how this could benefit us but it should go in the client section. Not project section.
Project Sponsor. is this different from Project contact?
Project complexity. I could see how this would be helpful to class your project types for quick project creation. But it does seem like extra info that for me personally would just be an extra field that would or would not get used.
Project type. seems like that is what modules is and that is what he has associated with it. Modules are already attached to the projects.
Project class. As I write all this down I get the feeling that many of these would be repetitive and managers would get confused. I would need to give some serious classes to what the differences would mean.
Overall I do like the notion of being able to create projects with default stuff that is the norm of (the companies) projects. Quick and Easy.
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.
1 to 5 of 5
Comments are closed.
For more Intervals help documentation, please visit help.myintervals.com