The following is a presentation based upon notes about our Work Organization.
We have lots of detail, not well suited for presentation or planning. We need to improve our data, and then provide tools to create, maintain, and query the data.
Divide (and conquer) the big list of details into sets small enough to be comprendable, and big enough to avoid having too many sets.
Work that is of high visibility/importance/interest may deserve a sub-category which would otherwise result in an overly small set.
Presentation implies a division that our clients can relate to. It should be about the computing they experience, and their expectations. So it shouldn't involve technical details. It should admit to broad overviews as well as increased (non-technical) detail.
Our planning should result in improving computing support to our clients. However we have to worry about the technical details. So we'll likely need to divide our data according to the technologies/processes/procedures used, and plan using both that and the presentation data. This categorization likely won't be used much for presentation (outside of CSCF).
One approach would be to consider the various computing environments our clients experience.
We could start with our major computing environments (student.cs and core.cs), and add to that.
Examining a large sample of work items has suggested some sub-category names for services
The name of the category, "Service" is controversial.
Examining a large sample of work items has suggested some technologies and approaches.
The current name of the category is "Component". "Building Blocks" or "Implementation Details" would work, except a single word is nicer in column headings.
The natural cry of support organizations is that they spend all of their time fire-fighting. This category is intended to help understand the extent to which that's happening, and the causes. While not strictly necessary for presentation and planning, it seems worthwhile. The category name, and the sub-category names, as with all the other, are subject to debate.
RT has been gradually changed to facilitate grouping data in two ways.
This is an overloaded word. We currently call our proactive work "projects". That word has a different, specific meaning to project planners. We'll take it to mean the dependency relationships between work items.
To facilitate grouping related work, there's a "create" button beside the dependencies list that makes it easy to create new work items as dependencies of an existing item. It's possible to create an entire tree of dependencies given the subjects, indented to reflect the tree structure. Details are provided in the documentation for the "dependencies" field.
There is now a generalized keyword mechanism that can be used to group related items. It's available in the theme field. It uses hierarchical keywords; they look like pathnames.
The generalized keyword mechanism was used to experiment with choosing the categories described earlier. Even though the three categories have become separate fields in the work records, this mechanism will remain, as it can be handy for ad-hoc situations. E.g. it was recently used to associate multiple levels of budget spending with the associated work items, as an aid in determining what to spend next.
The display of data has been extended in various ways. The additions are accessible (only) by the RunOn Sentence. There are a few features (not described here) that remain to be added. The Help Button for the RunOn Sentence provides details.
In general, each selected item is replaced by a specified subset of the related items. By default, that's just the item itself, so you see no difference. The "showing" selection at the beginning of the third last line of the RunOn Sentence is used to select relatives of interest.
The queue display is now capable of displaying dependencies, using the "showing Children as Well" selection (on the third last line).
The queue display is now capable of displaying the ancestry of an item, using the "showing Ancestors as Well" selection (on the third last line).
This display now always appears in the item update, to augment/complete the existing dependency display.
The gain an understanding of overall causes of work, each selected item can be replaced by the root of the dependency tree to which it belongs, using the "showing Just the Leaders" selection (on the third last line)
The RunOn sentence now allows one to specify field names to display. Appending a "+" to a fieldname causes it to be totalled across the complete dependency tree of the children of items.
It can't be specified yet, however the group titles can also be told to include totals of specific fields. It's currently defaulting to "time_worked, cost_estimate".
We have fields, called Service, Component, and Advancement, that we want to query together. The catch is that we won't always have a Service specified. So the grouping mechanism is smart enough to be told to use/display the first N non-empty field values. E.g. as seen in Requests created since 2010/08/24.