02/24/2009

11 am, N42-286, CSS Managers 

Agenda

  • Resource Models: How can CSS use this information?  Desired Outcome: Agreement on a draft plan on how best to use the information collected in the Team Resource Models.  Answer the questions: What are the benefits of collecting this data (to CSS/IS&T/MIT)?  How can the data help CSS teams, help each other? How is this data going to be used? How often should we be updating the Resource Models?

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 managementenvelope ) 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 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 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 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.  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.) from 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.

One useful question likely to reappear is "if we cancel this project, what resources will it free up?"
Tim reinforced the point of "What are the questions that the data needs to answer?"

Mark mentioned these issues:
a.) you have to capture time;
b.) you have to have people willing to be honest with you;
c.) each reporter needs their own work labels for work that 's unique, and shared labels for work that is the same.
To be successful, the group of us needs to commit to collecting time, and all the other stuff that ought to be known.

Barb's summation:
- as good as it gets for the moment is for each manager to have their own model that they commit to maintaining
- but it seems early to share because it wouldn't make sense to another view;
Kate's response, maybe it would be valuable to understand the list of categories per team against which %s are allocated.   

Agreement around the room to send Rob each team's list of task names, to be aggregated into a single list, preserving the breakdowns by team, ultimately to be posted on the wiki for all to see and learn from.

  • Quick overview of RT Enhancement project underway.  Pat Sheppard, Oliver and Steve Turner have been in conversation with Best Practical on steps to both get us up to a more current version of RT and carry out some much needed performance enhancements.  I've asked Oliver to give us all a quick overview of this project and where it stands.  (goguen - left over from last week)

Oliver recapped the current issues:
a.) RT has been degrading in performance over the last few months, a lot over the last few weeks.  Varies with load, including spamming to en email list generates tickets. 
b.) there are few developer resources available to do performance tuning, etc. 
c.) NIST is stretched thin when taking on services like RT, including the web server, DBA work, etc.  Mark did some heroic work Monday night to keep things running better.  Relying on Mark's heroism is not a sustainable state.
d.) wilson is pushing to have Best Practical do most of the tuning and enhancement work on RT, under Pat Sheppard's spearheading.  The current plan is to have BP assess the running system and make recommendations, which would be run past NIST before application. 
e.) Oliver does not believe that we can get along with just BP and Mark running RT.  But no one else in the organization wants to step up as yet. 
f.) there is also no one left on tooltime-team.  Steve and Oliver have been doing it ad-hoc so far.  Maybe there should be a training class or better documentation of queue menagement. 
g.) BP will be absorbing MIT customizations into the core as part of this operation.  

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)

Not enough time for this agenda item.

  • Anne round-table: SAP update reminder functionality is being used to prompt managers each month to check SAP for errors in epsnding or whatever and let Quentin know.
  • Jon round-table: TSM Energy tool got the attention of Terry Stone in the ideabank, and so it's much hotter now than it was two weeks ago; Theresa has offered up resources to take care of it.  More to come...
  • No labels