Two enhancement suggestions: cost tracking and linked copies of projects/issues
There are two things that would significantly enhance the value of redmine as a comprehensive project management tool for the sorts of projects i use it for. They're not directly related other than through this post. I am pretty sure either could be implemented as either a core change or a plugin.
It would be a big help in cost tracking to integrate it with Redmine. If one uses Redmine as the controlling data set for hours spent and for issue/project timing, it makes sense to integrate cost controls rather than manage those separately and have to maintain two data sets with significantly overlapping data.
I'm sure there are better ways to do this, but in my mind I'd like to be able to associate both or neither a fixed cost and an hourly cost in two places:
Per Issue Cost Tracking¶
Each issue might have either/neither a fixed cost and/or an hourly cost.
- A fixed cost applied to an issue and allocated to the project balance as soon as an appropriate issue status is applied such that the cost is allocated when the issue becomes live, not when it is conceived.
- An hourly cost would allocated to the project as the hours spent are updated. I imagine this tracking the hour modifications, accrued in full at the update time, and subtracted at the time adjusted if the hours spent are revised down.
For example, if a issue is to buy the team a celebratory dinner for completing the subproject, one could allocate the budget for the dinner to the issue. When the dinner is marked as "complete," the cost of the dinner would be allocated to the budget. or as another example, an outside consultant might be assigned to a issue at an hourly rate. Each time the consultant updates with additional hours spent, the cost-rate would be allocated to the issue and to the project
Per Asset Cost Tracking¶
Each person (more generally, each asset) assigned to the project would also be allocated either/neither a fixed cost and/or an hourly cost. There are two additional modifications to the "assignee" concept that would make this much more powerful:
- Each issue could be assigned to more than one person/group (or, conversely, each issue could have more than one asset assigned to it). Each person/group assigned to a issue would have their own hour tracking entry. This would enable cost tracking per asset, where those assets might not all have the same cost basis.
- "members" of the project could be expanded to include non-person assets, each with either/neither a fixed cost and/or an hourly cost.
For example, a project may require renting a compute farm to pre-compute rainbow tables at some fixed set-up cost plus some per-hour cost. One would create a "Rainbow Table Compute Farm" asset and define the setup and hourly cost. For each issue that requires the compute table, by allocating the RTCF asset to a issue, and estimating the hours required, the cost of the issue would be computed automatically and the budget projection, cash flow, etc metrics updated
This would provide projects very useful information including:
- Actual running cost of the project
- Actual vs. projected cost ongoing at at the conclusion
- Updated actual costs to use as a basis for future projects.
Projects might be repeats of previous projects; multiple identical projects may be running simultaneously; projects may have identical parallel subprojects. All of these cases would be easier to handle if it was possible to make associative copies of projects and issues.
What I imagine is that instead of just copying a issue and whether to copy one or more of a list of items from the parent issue (useful and powerful), one could additionally specify what fields are linked and what are independent. I imagine this being primarily an atomic definition, that is linking or delinking on a per-field basis. I'd like to do this within a project at the issue level and at the project/subproject level.
Associative Subordinate issues¶
At the issue level, if I copy a issue, I'd like to be able to specify via a series of checkboxes what fields are linked and what are editable in the copy. If I try to edit a linked field in a copy, I would like asked if I want to edit the parent field, in use in the following issues or delink the field in the copy of the issue, making it independent.
If one wants to associate a field between two issues later, then the user would be informed that any data in the subordinate linked issue will be deleted and replaced with the value of the dominant issue.
For example, I have two failover VMs that need to be configured - the first issue I define is the primary and, for example, all the instructions are included in the text field as is the estimate of the hours, estimate of costs, and resources allocated. I create a linked copy for the second VM making hours spent and assets allocated delinked. If I update the instructions in the text field, both issues reflect that update because those fields are linked, but hours are tracked individually.
Associative Subordinate Projects¶
At the project level, I'd like to be able to maintain associativity when I copy a project. In my mind, this means specifying what issue fields are linked for all the issues in the project at the time of copy, while per-issue customization could be done later. As a UI matter, it might mean two copy options - a normal, non-associative copy and an associative copy. If an associative copy is selected, the user would be required to specify which fields are associative and which are unlinked. I would prefer that the current values in the dominant project, the one being copied, are copied as default values to the subordinate copy, or whether unlinked fields are blank in the copy.
In addition, if a project has one or more associative subordinate copies, if a new issue is added to the dominant project, it should appear in all subordinate copies as well with the same field associations defined initially.
For example, if I have a project to set up a server and I make a subordinate copy of that task, making only the hours spent non-associative, then if I modify the instructions for network configuration in an issue, those should be updated in all subordinate copies of the project. If I add an issue, for example setting the host name, that new issue should be created in all associative subordinate projects.