Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Timesheets: What are they good for?

by eyepopslikeamosquito (Canon)
on Apr 16, 2005 at 00:25 UTC ( #448385=perlmeditation: print w/ replies, xml ) Need Help??

Though we don't have any "client billable hours" all our developers have to fill out timesheets in order to gain R&D tax concessions from the government.

You fill out your time, in 15 minute intevals, on various development projects, and in various categories, such as: requirements, design, code, code review, test, bug fixing, talking about the cricket, and so on. I don't enjoy this administrative chore yet accept it's necessary to get the concession.

However, it's recently been suggested that management might begin to use this timesheet data for other purposes, such as assessing individual programmer productivity and performance and for payment of bonuses. This worries me. Once programmers realise you are doing this, they may start telling lies on their timesheets, thus ruining any value the data may have.

I often take specifications home to read on the train ... or uncover a new design idea in the middle of the night while sitting on the loo. How do you enter this sort of thing into a time sheet system? And how can you verify its accuracy? I also fear an overly onerous timesheet system may stifle innovation and creativity and make it harder for us to attract and keep quality developers.

I'm interested to hear about what you do. Do you fill out a timesheet at work? What is this information used for? How is its accuracy verified? What granularity (e.g. 15 minute intervals) and categories (e.g. requirements, design, code, test) do you use?

Comment on Timesheets: What are they good for?
Re: Timesheets: What are they good for?
by bageler (Hermit) on Apr 16, 2005 at 03:36 UTC
    we do it in my company for accountability and to bill clients. Everyone in the company telecommutes so it's important for the suits to keep tabs on how we spend our days. 15 minute intervals. Our system is divided into client-project-task-activity. It's actually a cool system, I wrote it as my first job for the company :) Activity is stuff like ('other','development','correspondence','meeting','template coding',...). The rest are pretty self explanatory I think. Accuracy isn't per se verified, the important thing is that we get the job done.

    There's an internal company project for research that I use to record the time I spend here :)
      My last job we filled out paper time sheets, and accountability/verification was very lax. The data was used for payroll only.

      My current job requires programmers to punch in and out. I haven't been here long enough to figure out what they're using the data for.

      If you give a man a fish he will eat for a day. If you teach a man to fish he will buy an ugly hat. If you talk about fish to a starving man, you're a consultant.
        Used for payroll? Lucky you!

        At my last job everybody was required to fill out a (badly done) html page which emailed the payroll person your hours. They were supposed to use that in paying us - yet the tech staff were all on a salary so no matter what we put it never matched up to what we got. The stupid thing is that we were even told not to "rock the boat" by putting our real hours down.

        So faced with the dodgy task of having to fill out a time sheet that nobody took of, with incorrect data .... I whipped up a script that submitted the timesheet for us.

        Weekly reports were a joke as well .... but that's a completely different story!
Re: Timesheets: What are they good for?
by Qiang (Friar) on Apr 16, 2005 at 05:10 UTC
    I just write down the hours i worked for the day, morning and afternoon. that's all. well, as long as we get the job done :)
Estimating future project timescales
by barbie (Deacon) on Apr 16, 2005 at 07:15 UTC
    However, it's recently been suggested that management might begin to use this timesheet data for other purposes
    This is often a concern when a system is introduced, but in my experience its never been the case. My staff and I currently fill in timesheets, in the catergories you mention, in roughly 15/30 minute chunks. The aim for us is to better gauge how much effort is put into a project, so that further down the line when we have a feel for how much time is spent in all the areas, we can better estimate how long similar projects are going to take. It saves us from trying to meet ridculous deadlines.

    Timesheets should never be used for "assessing individual programmer productivity and performance" as there can be all sorts of factors that are out of the control of any one programmer. What if requirements were poorly defined, and they've had to go back and rework chunks of code, is that the programmers fault? Anyone who uses simple time based metrics to gauge performance is either a bad manager or they are not the company you want to work for.

    As for measuring/recording time spent working in your own time or coming up with new ideas, this can be a difficult one. I personally don't, even though I do it most of the time. As do all my staff. However, it is one thing that I do look favourably on when appraisals come up. And perhaps I should mention I've never used timesheets in an appraisal, except to remember all the projects that someone worked on. Then I am more interested in how well they performed not how long each project took.

    --
    Barbie | Birmingham Perl Mongers user group | http://birmingham.pm.org/

      ++ tracking performance with timesheets is not a good thing at all. But I had the unpleasent experience of being mesured that way.

      The result was that people started to simply to be on time with "implementation" by skipping parts of it and the things that weren't finished in the initial coding phase was pushed on to bug-fixing(unfinished implementation details are bugs right?). The result of this was a drop in code quality because the allocated time for bugs wasn't enough due to the covering of the delay in the initial implementation of code.

      Time based metric is even worse than LOC count measuring.

        Another example. I know of a company where they measured the "performance" of their support section by how quickly they closed open tickets. As you might expect, the support folks began boosting their performance rating simply by closing a ticket ... then opening a new one! Now, this annoyed the customer (who was told to start referring to a new ticket for the same problem) but, hey, they got their bonus for improved performance! The lesson here is that metrics become unreliable as soon as they are used as a basis for reward/punishment. Perhaps the best way to measure performance is from outside the team: for example, the performance of a support section is perhaps best measured by asking the customers how satisfied they are.

Re: Timesheets: What are they good for?
by g0n (Priest) on Apr 16, 2005 at 09:17 UTC
    I fill in three different timesheets once a week. One tracks the number of days I've done for the agency I work through, another relates to a single project and is easy enough, but the third!

    That's used for client billing, resource utilisation tracking, forecasting, MI & project budget calculations. Also apparently it's used in performance assessment (although I wouldn't know for certain). In order to be paid for the time one has been on site, one must book a minimum of 40 hours a week to projects in this third timesheet. All team meetings, administrative functions etc must be absorbed into projects. Waiting on dependencies must be booked to something, or one doesn't get paid for the unbooked period (calculated by and rounded up to half days).

    It isn't popular.

    Oh yes, and not completing it to accurately reflect your activity is a disciplinary offence (see 'team meetings & administrative functions etc' above and try to figure!).

    g0n, backpropagated monk
Re: Timesheets: What are they good for?
by rg0now (Chaplain) on Apr 16, 2005 at 20:54 UTC
    We have to fill in a stupid Excel timesheet every month to document our activity, which is then printed to paper and sent to the management.

    Boy, I do not even have Excel installed... Instead, I have a nice Perl script that generates random activity for me saving me countless hours of doing silly paperwork. I once set it up to give me a healthy balance of research work and coding, and lately I have grown to copy-paste the generated random report into Excel (on a colleague's Windows box) unchanged, without proofreading it any further.

    Curiously, the script used to have a strange error, which caused it to produce fake reports every now and then, but I have never been contacted on this issue. Apparently, they just throw the timesheets away...

    rg0now

      Or they've spotted it and are saving the information for a better time...
Re: Timesheets: What are they good for?
by cog (Parson) on Apr 16, 2005 at 21:14 UTC
    Back where I was working, I didn't have any control over the hours I'd work.

    My boss used to show up around noon and he would leave before six...

    One week (one rough week), I had to do some weird changes to my schedule. There were days in which I was the first to get to the company, and there were days in which I was the last one to leave.

    However... there was a day in which I arrived after my boss and another in which I went home before him...

    He assumed I would always get there just before he did and leave as soon as he did... and thus he called me to his office, for the reprehension.

    Regardless of what I'd tell him, he would just not believe me...

    From that day on, I started noting down my working hours (1). I'm not doing it for them. I'm doing it for me!

    (1) - Oh, and as soon as I realized I was working *way* too many hours, I started working less; afterall, they weren't valuing me enough.

      I had to do something very similar. I started as a contractor and noticed that when I was hired that my hours came under serious scrutiny (primarily because I come in around 9:30 am to 5:00 pm, and then from 9:00 pm to around 2:00 am). I too started tracking my time and the very next time that someone fired off a snide remark I went back to my desk, printed off a week's worth of timesheets and then promptly presented the crow to be eaten sans fork ;-)

      I haven't had anymore trouble about the hours that I work

      -Jim

Re: Timesheets: What are they good for?
by Mabooka-Mabooka (Sexton) on Apr 18, 2005 at 00:25 UTC
    I have to do a so-called "weekly status report".
    My boss always reminds me to do it by e-mail.
    Or... I don't do it for months.
    Actually, I think it's useful -- if you have end-of-the-year performance reviews, or want to update your resume...:-).

    Whatever impact it might have on you, make sure to reach the status: "If my boss starts to really p.ss me off, I'll just move to another group / company". This'll help.
Re: Timesheets: What are they good for?
by Anonymous Monk on Apr 18, 2005 at 09:34 UTC
    I have to do timesheets as well, although in the two years I work here, I may have had 30 client billable hours.

    Our department hardly makes money from clients directly, yet we maintain the most profitable software our company has. But we get "hired" to do work (typically, on a project bases) for other departments. Projects which can take a few hours to a few years. We use time sheets to keep track of how many hours we spend on a project. This information is used for several things. One of the important things is to determine how much money other departments have to pay us. And it's used to measure how well our estimates on how long the project would take were. There's also global analysis done, to see which products take more to maintain/develop. AFAIK, the numbers aren't used for tracking individual prestations - and it's certainly not used for performance bonusses (our performance bonusses are mostly based on how the company is doing as a whole, with only a small variation in individual bonusses - you've got to be really remarkable (either way) to get more or less than the average)

    I hate filling out the timesheets, but I do recognize their value for the company. We can use up to 15 minute intervals, but I usually estimate how many hours I've spend on a project on an entire week, and average that out over the days. But that's easy as I usually only work on one project. Projects are typically subdivided in subcategories (knowledge gathering, development, testing, documentation, delivery).

Re: Timesheets: What are they good for?
by Mutant (Priest) on Apr 18, 2005 at 11:40 UTC
    Timesheets for client billing makes some degree of sense (although I still hate filling them out).

    Timesheets to measure productivity are completely pointless. Hours worked (or hours in the office) has almost no bearing on productivity. Measuring this is a far more complex process, although one obvious factor is whether a project was completed on time, on budget and met all agreed upon requirements.

    I think flexitime for programmers is essential (so long as they're available for meetings, etc). I might spend 4 hours of the day and complete 2 days worth of work, but forcing me to work another 4 hours wouldn't necessary equate to even 4 more hours worth of work (and could lead to me burning out). A smart manager will recognise this. Fortunately, I currently work with managers like this.
      But timesheets can work beneficial for the programmer (or whatever position you have) as well. If a manager asks why a specific project hasn't been finished, you can point to him how many other projects you have, and how you've allocated hours to the various projects.

      And then you can use that as a basis to come to a different allocation of hours.

Re: Timesheets: What are they good for?
by Ninthwave (Chaplain) on Apr 18, 2005 at 12:06 UTC

    I do timesheets for client billable work and for internal work. I find the system for the type of work I do to be a bit silly. But we have done some things to hlep make it easier. We have an application that queries on 15 minutes to enter the task you are working on. If it is still the same you can just ok it and keep going. I do have a problem with the hours out of office as occasionally an epiphany will come and I find myself booting up and doing some code in the middle of the night. Which I then have to enter into the system and do the explanations for. But the company I work for weighes results before anything else so I am not really pressured about it.

    Now as for making it a metric. For any metric to work, an understanding of the work process must happen. For people coding, talking about cricket is important. The down time where you can subconsciously or peripherally reflecton the task at hand is valuable. Fresh eyes and fresh minds help the process. If this is not understood by the people using the metrics you can find artifical limits or performance guidance set. At the same time, I have found people are different in how they approach tasks and how optimally the work in given constraints. Some people who see down time in the work enviroment will abuse it. How do you see this in recorded metrics of the type you site without first reviewing the quality of work produced. It seems the metrics being asked for would only be secondary to a higher level metric.

    Every company is different, every team is different, every person is different and each task is unique.

    "No matter where you go, there you are." BB
Re: Timesheets: What are they good for?
by bofh_of_oz (Hermit) on Apr 18, 2005 at 14:57 UTC
    I would say that it depends on the business policies and on how strictly one is supposed to follow them...

    On my previous job, we were told to fill out timesheets... However, as there were only three people supporting network/Wintel servers/users etc, we decided we do not want to spend time on paperwork and the project promptly died...

    In my current company, the timesheets are submitted weekly and are strictly enforced. The official reason is "...to track the time needed for the projects for the purpose of better resource management", although I believe the main reason behind them is the quarterly performance reviews...
    The categories are selected from existing list (that's what the PlanView administrator is doing, building those categories); any new category I feel could describe my tasks better, should be properly documented and approved by an immediate manager.
    The granularity is not strictly enforced though... you just enter a number in a box, it could be 1, or 1.5, or 1.25... The main goal is that in the end, there should be 37.5 hours of regular work per week.

    All in all, I think it comes down to the question: Am I paid well enough to cope with what I believe is unproductive and/or plain stupid?... I know I am now, although that perception might change later :)

Re: Timesheets: What are they good for?
by 5mi11er (Deacon) on Apr 18, 2005 at 22:31 UTC
    I agree with one of the first replying posters above, that few organizations actually implement those plans.

    Management may desire to use the data for "other things", but any intelligent person/organization (which are admittedly rare) will see there just isn't enough detail to use that information for performance rating.

    Billing external customers is pretty much the only intelligent reason to require a time sheet. Even if that "external customer" just happens to be your boss...

    -Scott

Re: Timesheets: What are they good for?
by ciderpunx (Vicar) on Apr 19, 2005 at 11:13 UTC

    > However, it's recently been suggested that management might begin to use this timesheet data for other purposes, such as assessing individual programmer productivity and performance and for payment of bonuses.

    That strikes me as a rather ineffective way to measure 'performance'!

    Say you write a fantastic piece of code in 10 minutes, when you were expecting it to take an hour. Using the performance=hours worked metric, there's an active disincentive to move on to the next challenge for the next 50 minutes! You end up with a company paying programmers to read slashdot/PM/whatever (not that any of us would ever consider doing such a thing ;-) ).

    It does raise the question of how one might measure the productivity of coders. Sometimes the most productive thing to do is delete everything and start from scratch, sometimes things take less or more time than expected, you know the score...

    So is there a way to measure productivity that can be generalized for most programmers in most environments, or is it something that we just can't measure meaningfully?

      Well, that depends on how they measure performance. I doubt they measure performance in "hours worked" - after all, many people will have a contract which already says how many hours they have to work. If performance is measured by looking at the ratio of "projects done/hours worked", with larger projects carrying more weight, than browsing the web for 50 minutes out of an hour brings your performance down.
      It does raise the question of how one might measure the productivity of coders.
      Indeed. And one should realize that measuring performance isn't only done because managers like to do just for the heck of it. If you want to get a raise, or a performance bonus - or when it's a matter of keeping your job when there are lay offs, you benefit from an objective measurement of performance as well. Because you will be competing against the other programmers.
Re: Timesheets: What are they good for?
by trialmonkey (Hermit) on Apr 19, 2005 at 13:06 UTC
    Time sheets a good for measuring activity, not performance. Unless you're a consulting company (mostly concerned about billable hours), there's a big difference between the two.

    Ideally, the timesheet information is used to build a database of metrics that are fed back into project estimation process. If you're development processes are consistent, this is useful. However, I've rarely seen this implemented successfully.

Re: Timesheets: What are they good for?
by the_slycer (Chaplain) on Apr 20, 2005 at 00:43 UTC
    Where I work, the timesheets are incredibly complex.

    The granularity is such that they actually have a timesheet code for entering the timesheet.

    This applies to everyone in the company (roughly 100 people). Of those people, 14 are IT.

    We had a new director come in a year or so ago, once he saw the time wasted on entering timesheets, and knowing that they weren't used for anything, he promptly put an end to it for IT.

    A while back, we were told we were going to have to start doing them, but I've seen nothing come from it, and I don't think anymore will.
Re: Timesheets: What are they good for?
by castaway (Parson) on Apr 22, 2005 at 05:38 UTC
    According to our higher-ups, Timesheets are good for figuring out how far along a project is at any given point, and thus how much we can bill the customers.

    They are also used to keep track of: Sick days, vacation time taken so far, Over/Undertime, and productivity %. (This last is a measurement of how much of my time actually goes on billable projects).

    Ours are Excel timesheets, with references to centrally maintained project lists, so every row I create contains an approved project name (some of which are internal things like "Work environment/tools"). We enter the arriving/leaving/lunch times, and then have to distribute the remaining hours among the chosen projects.

    The only thing I've seen change which might indicate that anyone reading/using these may care about productivity, is that a "project" called "Non-productive tasks" got removed from the list completely, presumably too many people were using it.

    C.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://448385]
Approved by Golo
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (8)
As of 2014-12-25 22:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (163 votes), past polls