

Effort Tracking¶

This page describes a simple plan for tracking effort in the OSG Technology teams.

Basic Ideas¶

At its simplest, we would like to understand how much effort is spent on various OSG Technology activities over time. The focus is on having reasonably accurate, unbiased data. We might use the data later, for example, to hone future OSG proposals. And of course, all federal funding is subject to effort tracking.

There are just a few simple ideas to keep in mind:

Each week, report your effort on OSG Technology activities

Update your numbers in the effort tracking google spreadsheet (ask BrianL for access) and include a section in your weekly status report; here is an example:
```
EFFORT
External development: 63% 
Support: 12% 
Leave: 20% 
Outside: 5
```
Follow standard federal regulations for calculating effort (e.g., OMB Circular A-21)

The main idea is that all of your job-related activity for a week equals 100%, whether that is exactly 40 hours of work, a little less (subject to your local institution’s rules), or more. This implies that the same hours worked could result in different effort percentages reported from week to week; for example, 4 hours in a 40-hour week is 10%, but 4 hours in a 50-hour week (which I hope is exceedingly rare) is 8%.

Report 100% of your effort each week, but note that all effort outside of the Technology area falls into a single category. Unless you work at UW–Madison, we do not need to know any details about your effort outside of the Technology area. (BrianL will talk to UW–Madison folks about local expectations.)

If you are assigned to the Technology area for less than 100%, please report your actual Technology effort accurately. Workloads vary from week to week. For example, suppose you are 50% Technology in general, but you actually work 24 hours in a 40-hour week; you should report 60% effort for that week. The goal is to present reality, not what you think management wants to see.
Effort is reported as integer percentages, no less accurate than 5% intervals So please do not report percentages like 43.21% and please do not round to the nearest 10%.

Effort Categories¶

Here are the categories in which to track effort:

Investigations	Work on the Investigations team
External	Software work that (generally) benefits our users; e.g., creating packages; updating existing ones; designing, coding, and testing new tools, existing tools, patches, or our software components
Internal	Software work on tools that we use to get work done; e.g., working on osg-test (for now), osg-build, Koji maintenance, the UW or UC ITB instances
Documentation	Work on our TWiki or Markdown documentation
Release	Release team activities, primarily acceptance testing and cutting releases
Support	User support, including working on GOC tickets, direct support emails, some JIRA tickets that are more support than development, etc. It might be tricky to decide when support work becomes development work; generally, once a support ticket turns into a JIRA ticket and goes through the normal development lifecycle, then the JIRA-based work is development. If there is still extensive communication with GOC ticket users, that is still support.
Management	This is mainly for team leads; e.g., managing team activities and tickets (generally); hiring; leading (not just attending) meetings
Education	Not for general learning or training activities The OSG Education area is essentially part of the Software area, because many technology-area members contribute to the OSG School. So this category is for OSG School effort (or other sanctioned OSG Education activities.
Admin	General administrative activities that benefit the OSG Technology area but that do not fit elsewhere — use sparingly!!
Outside	For all activities outside of the OSG Technology area (Madison team members should provide extra details, see BrianL)
Leave	This is for holidays, vacation, and sick leave; count a full day of leave as 8.0 hours, count a half day as 4.0 hours

A few thoughts about tricky situations:

Meetings. If a meeting is specific to one of the categories above, use that category. If the meeting is more general (e.g., the weekly Monday meeting, or the OSG AHM), amortize your time according to your usual breakdown by category. For example, someone who spends nearly all of their time working on development tasks should count the Monday meeting as development time.
Administrative activities. This is probably the trickiest category. It certainly covers any administrative work that pertains to your activity in the OSG Technology area. But what about administrative activities that pertain to your employment in general, and not to any particular activity? In that case, and that case only, you should amortize the administrative activity between Admin and Outside according to either (a) your appointment percentages between OSG Technology and non-Technology activities, or (b) your actual percentages between OSG Technology and non-Technology activities.
Outside (non-Technology) activities that benefit the OSG Technology area. The simplest approach is to amortize the time. The more correct approach is to figure out where credit will be given for the work; if the OSG Annual Report will describe the work in one of the Technology sections, then it should be a Technology category; otherwise not.
Learning activities. Put short amounts of learning time in their relevant development category. For instance, if Igor is showing Edgar how to use GlideTester, that goes into Internal. But for longer training events, or for events that are less obviously related to day-to-day activities, mark the time as Admin, and maybe add a comment explaining the activity.

Ultimately, if you are not sure how to deal with a situation, ask BrianL and he will make something up and document it here (generically) for future reference.