...
Kate led a discussion on how RMs were ever used and is there a way to use them better within CSS?
a.) capturing staff time on specific named work (like projects) that want to be totalled up to see how much the total contribution of everyone amounts to. Drives a financial view of any particular effort. "Costing a line of business" in Anne's parlance.
b.) individual managers are interested in knowing how their staff is deployed, to understand (within the team's managementmanagementenvelope ) understand if they're deployed right.
c.) analyzing revenue models to drive billing for the time spent. DITR and DCAD use it this way.
The RMs are useful bases to answer the management questions that come along about "how much of FTE is going to something". When asked an ad-hoc question, the data to draw on is already there.
It's just a good management practice.
Time reporting certainly makes the tabulation possible of what they are doing, versus what they're being told to do. The lack of a consistent effort in this area undermines the usefulness or constitency consistency of the data.
Have a list of questions like what do we want to know, and then generate the data accordingly.
A Wilson question may be very different than a Jerry or a Terry Stone sort of question.
Anne remarked that the current focus seems to be how much time and mondey money is being invested per product or service.
Another use of the model is to know whether certain resources are or aren't available for borrowing. Nowadays a manager needing someone goes and asks. This Shared visibility isn't "necessary" though providing a preview of it was the original reason for the previous resource model; to accomodate questions from SAIS and ISDA about CSS resource availability.
The challenge lies in answering multiple questions (time, product line, etc.) at the same time, all the timefrom tbe one data pool, repeatedly, ad-hoc, and on short time lines. It seems to Jon like a lot of investment for not so much return. Everyone would benefit from being asked things earlier, instead of requiring night-before fire-drills.
...
Agreement around the room to send me the send Rob each team's list of their task names, to be aggregated into a single list, with preserving the breakdowns by team retained, ultimately to be posted on the wiki for all to see and learn from.
...
Rob remarked that Helen Rose is interested in an RT-Partners group. Oliver remembered rt-users, though it isn't used anymore.
h.) there is no data archiving policy for what to do with the data in RT. The RT server will fill up with, say, deleted tickets unless we set some practice for actually getting rid of them. There is a piece of software called the RT Shredder that can deal with this complicated issue of interconnected data elements. (Users, groups, attachments...). Sadly, RT Shredder is a few revisions behind the current RT version and is risky to start using, let alone we don't have a copy of the working system to test on, etc.
The thought is to make the warehouse feed turn into an archive of the ticket metadata over time (as it is now a snapshot of the current RT database, refreshed daily.) Steve is working on this with the warehouse team now. If you delete a ticket from the server it will diseappear from the warehouse.
- Thoughts on priority projects (goguen - in prep for VP staff meeting on Thursday)
...
| Wiki Markup |
|---|
\[[\*|Pattern of Persistent Agenda Items]\]\\ |