Fog Creek Software
Discussion Board

Benefits of Timesheets

I wonder what the JoS crowd think of timesheeting systems? I mean more than simply billable hours, but *where* the time went, *what* you did, applied to all employees.

I worked under a timesheet system previously, and it was amazing the lengths people would go to put something into those slots. I have mixed feelings about them.

A) They can give you an indication of how everyone is working and perhaps which areas are really dragging everything down. Possibly symptomatic of communication problems in your team.

B) Heisenberg's Uncertainty Principle. By observing your employees in this way, you may end up changing their behaviour. For better or worse depends on the situation, but I am reminded about the dangers of performance metrics.

C) Timesheets gloss over important things like interruptions. It's frightening to look at the COOLDEV entry for 4 hours and think that all you managed to achieve was a few extra lines in a minor subroutine. Your managers will think the same thing, but quite possibly disregard the urgent support calls, emails, etc. etc. that kept firing off in this time. Your interruptees, of course, said it's only 5 minutes, so don't put it on your timesheet.

What are your opinions on timesheet systems in an IT workplace?

Joel Goodwin
Wednesday, April 2, 2003

Do you mean hour-by-hour accountings? Or just an accounting of billable activities?

If you have to account for every hour and what hour it is, that's dumb.

But if you have to keep track of how many hours you worked or projects A B and C today, that's reasonable, especially if at least one of A B and C is being billed out at $225/hr to your employers clients -- they HAVE to have this because that is where everyone's salaries are coming from -- your billable hours.

On the other hand if there is no client and you are just working on a single project then it should be something YOU and your project manager only know about and ONLY for the purpose of calibrating your performance metrics so that he/she can make more informed estimates as to resources needed and estimated completion dates for projects.

In any case, under no circumstances should these numbers be even be available for performance review, else the numbers will all become fictional rapidly.

Dennis Atkins
Wednesday, April 2, 2003

Oh and Joel, regarding the five minute interruptions - put down each individual one in the minimum accontable time period, which should probably be 15 minutes or so. Thus, if Bob asks you a question that takes 10 seconds, record 15 minutes to 'tutoring bob'. If anyone complains, tell them the minimum accountable time is 15 minutes and just repeat that over and over if they try  to say don't put it down.

Dennis Atkins
Wednesday, April 2, 2003

I assumed it was obvious, but the justification for 15 minutes is that peopleware and others claim that it takes 15 minutes to get back into the flow after ANY interuption, so you can even claim scientific legitimacy for this practice.

Dennis Atkins
Wednesday, April 2, 2003

I was severely anti-timesheet until recently. When doing estimates on a large project one of our team members trotted out historical data to figure what percentage of the time went to QA, what percentage went to documentation, etc.
The numbers may still be guesswork, of course...


Wednesday, April 2, 2003

"On the other hand if there is no client and you are just working on a single project then ..." etc

Unless you are based in Canada and can possibly claim those hours under the SR&ED tax credit program.  In which case you would feel dumb if you didn't track the hours, and then half-way through the year decided the project really was R&D...

I guess the point is that even if your job does not include any billable hours, you never know when it might be useful to have data on that point.  Ultimately, recording what you did all day is just good practice.  It doesn't have to be via a special timesheet program either - ideally you should be able to gather information with a minimum of context switching so that you aren't spending half of your time recording what you are doing.  Via CVS when you do a commit, for instance...

Thursday, April 3, 2003

And of course everyone in this forum thinks that they're good developers ...

Thursday, April 3, 2003

Timesheets are pointless, they presume to provide data that doesn't exist.  What matters is progress, obstacles and morale.

If its for contracting then all it does is tell you how much to pay them, if you didn't provide them with the work or materials, you still have to pay them, if you don't supervise them or monitor them then you still have to pay them.

For staff, it has even less point since for the most part you still have to pay them even if they didn't turn up (sick), spent an hour in a useless company meeting and so on.

If you get progress for less elapsed time than you estimated or planned for, that's a win, if you have an obstacle that impedes progress and saps morale then knowing how long it held you up isn't going to help solve the problem or improve morale.

Simon Lucy
Thursday, April 3, 2003

I'll just add an extract of a rant I'm sending to management about our timesheeting...

"When I mentioned that I needed some extra lines on the timesheet to record things like "trying to get UNIX support to pay me some damn attention and fix the NFS exports" so their cost in wasted time actually shows up I get told I can't do that. Monitoring the hours of time spent on things when the company happily burns whole days of time being inept just seems bonkers. I've asked - and I'm not allowed to book the costs properly to other teams when they won't do their jobs."

And that's why timesheets are a waste of time. They always end up a work of fiction.

Katie Lucas
Thursday, April 3, 2003

Time sheets are useful on a number of levels.

CYA: when somebody wants to know what you've been doing show them in excruciating detail.

Time management: most people wonder where all there time went, track it and find out.

One must track it before one can control it.

Don't complain that it is too much work. Lawyers track their time in six minute increments. It quickly becomes second nature.

Buy the appropriate software, if you need it.

Everything is "billable" to something, even if no money ever changes hands somebody is still accountable.

Anonymous Coward
Thursday, April 3, 2003

The timesheet system I used to live under was actually used for billing clients and clients were always unhappy to see "PROJECT DEVELOPMENT" and wanted to see a better breakdown. However, this system was also applied to internal projects and it's application clearly went beyond client billing but into performance monitoring. (Incidentally, only 6 entries were allowed each day which led to a whole truckload of problems, and our timesheets were edited before reaching client eyes)

If timesheets are suspected to go beyond billing, I think reaction to them is generally negative which can introduce more problems than they fix. Especially if you can't write what you want to sometimes, as noted by Katie above.

It seems more likely they are a rosy approximation of reality at best - what percentage of timesheets actually mean something?

Joel Goodwin
Thursday, April 3, 2003

The problem here is often developers don’t realize that someone has to pay the bills.

If your firm is involved in consulting and billing clients, then there is simply no excuse, or even a reason to avoid time sheets.  It would be the height of dishonesty to simply pull numbers out of a hat for billing purposes. That information is absolute required. If you have a project manager, and he is smart, then all the billing crap should be managed for the developers. (ie: you assign tasks and stuff to the developers). The project manager will know when that stuff is done. Developers should NOT have to deal with that stuff.

I remember working in the instructional systems department at university. We had to turn in time sheets. We hated that, so one of the developers actually sat down and write a nice little billing tracker program. All of the developers started using that program instantly.

Thus, if  a timesheet can be advised, then it should be, since developers as a matter of course hate that kind stuff anyway. If the developers do need to make timesheets, then give them some tools to do this.

Some building contractors I know simply are good at estimation the cost of a project. In these cases, you are talking about a fixed cost that is being given (bid) to the client. In that case, then you don’ need timesheets. The cost will be what they be, and the client will get a bill. However, you can bet that the construction workers punch in a clock, and punch out a clock. Hence, while the building contractor may be working on a fixed bid, your hours and wages are NOT fixed. Most contractors have a very good estimate at the start, and some just pad in a real LARGE amount so they make tons of money. (I know some that don’t even use a computer for $500,000+ jobs).  So what if the job runs a few extra days, it just don’t matter.

However, in software, we are not near as good at estimating the cost of a project. Since this is the case, then we often ONLY take projects where a estimate is given, but only sign on for billable hours. (in other words, much if not all of the software consulting business does NOT work on a fixed price).

However, lets assume for the sake of discussion, that we were like the contracting/building industry. Lets assume that we always DID bid on a FIXED PRICE.

The companies that I have written job costing for were those companies producing products, and in fact were profitable. However, the question was what is the cost of producing a product?  How much does it cost to making something? Often, a company does not know. Further, as a business matures, and more competition arises, then the need to know what things cost becomes very important.

For example, lets assume we are making dog houses. However, we have a 3 foot dog house,  a  6 foot house, and a 10 foot dog house. The problem here is which kind of dog houses make us more money? If I don’t know which dog house makes me money, then I can’t rally direct my company. Maybe those small dog houses have the same labor as a large dog house, but I can only charge a much less price. However, those small dog houses also use MUCH less material to build.

Without knowing which dog house makes me money, I can’t even tell the sales force what kind of dog house to try and sell! I don’t even know where to spend my advertising budget. I could tell the sales force to spend all your time selling the real big dog houses. However, those big ones might be money losers, since they use SO MUCH material (I can build 3 little dog horses for the amount of material as the big one).

So, really the concept we are talking bout here is a rudder to steer the ship. With no clue to what cost what, you are shooting in the dark.

This is exactly why timesheets, and some form of software Metrecs in a software company is needed.  A company resources are limited. Therefore, should you expand the support department that brings in revenue, or how about expanding the development department? Further, with software metric, you can find out what developers are writing bug free code, and which developers are not! Again, with no numbers, you have no clue as to which developer is good, or which developer is a dog.

Information on costs is what allows a manager to focus the direction of a company.

Why do you think baseball statistics are so important? All these stupid baseball statistics! I always hated them. I just want to go out an swing the bat, and play baseball (or maybe just have fun writing some software code).

However, lets say that the bases are loaded. You also have statistics on the pitcher. Those statistics state that when the bases are loaded, that 99% of the time, the pitcher will throw a fast ball, and it is going to be a right over the plate (a strike on the FIRST pitch, when all bases are loaded). It is possible that the pitcher  does not even know that he does this. However, if we do, then we have a huge advantage here.

If you know above stats, then you are now up to bat, then are going slug the absolute daylights out of that poor base ball. You will probably rip the skin right off the ball like Robert Redford in the move “the natural”.

Armed with those baseball statistics, you can improve, and be come a much better baseball player.

The same goes for software metrics. If you find out that 99% of your bugs are in occurring in your Winsock code, then you now certainly know where to work on improving your code (next time, your Winsock code will be written MUCH MORE carefully).

All of the above also applies to timesheets. They really are a form of job costing and proving the company with a rudder as to how to steer things. If  you only have 20 developers at your disposal, and out of those 20, 10 can write graphics code at double the rate of others, and the other 10 can write database code at the double the rate of other, then you can use this information to build  super team. Programmers are FAR MORE happy when they write code and do things at which they are good at. Those developers may not realize that they are good at GUI code, but terrible, or not very productive at database code. A good manager will use this information to make everyone happy.

So, we really are talking about job costing here. I have had to write some job costing systems, and the lessons I have learned had little to do with writing software.

Yes…you do need timesheets….

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Thursday, April 3, 2003

I am a project manager and timesheets are indispensible to me, not as a monitoring tool of other employees, but to monitor my own work. Let me explain:

At the beginning of a project, I work with dev leads to plan project time. We decide that feature x requires 3 days of dev time by Alice. Three weeks later Alice has finished feature x. I need to know that the dev lead and I were underestimating Alice's time by 80%, so I can get better at estimating how long it takes to do a feature with the complexity of x.

Timesheets help me get better at my job. The key thing is to use them only for that purpose and not as a way of hitting Alice over the head because she doen't work fast enough. Alice should feel comfortable enough to log in her timesheets that she spent only 20 minutes per day, for three week, implementing that feature. The rest of her time was spent on the phone to Bob in Kuala Lumpur explaining the finer points of using Windows XP.

As project manager, I have to avoid the temptation to think that "next time we won't be on the phone to Bob for 3 weeks". Because next time it will be Sue in New York. Unless I work with the dev lead to find another body to sit by the phone and answer XP calls.

Thursday, April 3, 2003

Oh, and even when (if?) I find that body, Alice will probably still have to train him / her. And then help him / her out when Bob phones and askes about feature x from the last release.

But hey, I'll have both of their timesheets to help me figure it out :)

Thursday, April 3, 2003

"No breakthrough without breakdown" - this is one thing I learned from one of my previous managers. Before you can manage you must be informed where are your costs and revenues or you would be second guessing.

From this perspective, time tracking gives us information on where project resources get consumed. A competent manager would correlate consumed time with project schedules and find the low productivity and problematic areas. Then it is possible to evaluate risks and priorities and make the right decisions before (not after) the critical path gets lengthened.

Although time tracking may look to some as a Big Brother’s eye, a competent manager will never use it as such. In fact there are many other earlier symptoms that point out an employee is unhappy and just about to have a breakdown.

Secondary, time tracking may be used for cost allocation and billing. But that's just project admin.


Thursday, April 3, 2003

Last time I used a time sheet application, it was a crappy one: I couldn't add my own projects, I couldn't add tasks and I couldn't plan my hours. The user interface was so painful to use, so most of my colleagues and myself postponed the time entry as long as we could. Then of course, we had to guess where the time went...

No, give me a tool I can use to plan my days. When the day is over, let me adjust my hours and confirm that day. Then all data necessary should already exist in the system so no one has to bother me again with the time entry.

Thomas Eyde
Thursday, April 3, 2003

I've designed job costing systems as well, one of them is still being sold.  Bugger all to do with software development, though.

I've yet to see a timesheeting system for anything which wasn't a fiction.  You might use that fiction to show costs, but you're only fooling yourself.

Yes lawyers bill in 6 minute increments, they also bill the same time twice to different client, the same clients or any permutation of the same.

Timesheets can be hidden behind, look I did research for 65 minutes...or you took a break had a conversation with someone in another department/company/universe in the course of the conversation about last night's game (which was brilliant btw), somewhere within the conversation was a sentence which related to the project and might just count as research.

Timesheets on their own count nothing except time, in order to apply any possible costing to it you have to code them to activity and code some notional cost rate to that code.  For anything except very well defined operations (and very well assessed operations), for people that work at a fixed job performing only known operations these costing systems are less than useless.

Unless a timesheet is filled in contemporaneously with the event, or the event is captured automatically the timesheet is going to be an actual fiction.

Its Monday, timesheets for last week have to be in for last week and coded.  Hmmm what did I do last week...

Ok, you can say its Time Management (big doomy voice), and everyone should be able to manage time.  This is no doubt true for those with regular colons and regular work schedules.  But anyone that thinks this is a Good Idea should also consider, which is more important, to do what I do, or remember what I did when I did it, how long I did it for and spend that time instead of doing it.

Ok, there is the point that if you're later going to capitalise the r&d costs that you have to account for them.  But that doesn't necessarily mean timesheets. 

Simon Lucy
Thursday, April 3, 2003

We have timesheets at my work that track our time constantly. Basically we have an always running intranet application and it's (usually) only 1-3 mouse clicks to record new activities (email, discussion with co-worker, phone, current project, etc). After you get used to it, it becomes second nature to record what you're about to do with a few mouse clicks before switching to that task.

The main reason for it's development was to provide a detailed bill for hourly rate jobs. However it also provides good feedback for time estimates so that we can revise time estimates regularly and continuously get more accurate with the estimate.

I can understand that some people would consider this a bit intrusive, but our management have said that they fully expect that there will be 20% of a persons work time spent on "breaks" - which counts for things like helping co-workers, simple support jobs, making coffee, day-dreaming, etc.

Thursday, April 3, 2003

Joel, don't timesheets go hand-in-hand with your painless estimating system? You've already got the timesheet - your estimating sheet.
Then, when the project is done, you can see how your estimates worked out. You can also look at the "penciled in" entries and note the things you didn't think about.

Looks like a feedback loop waiting to happen?


Thursday, April 3, 2003

Philo... err... <whispers>I think you mean a different Joel</whispers> Confusing, isn't it? Maybe one oof them should change his name.

Thursday, April 3, 2003

While we're on this topic:
Any suggestions of good timesheet management software? Is there any that can automatically track the applications being used on a desktop?

Samuel D. Jack
Thursday, April 3, 2003

If you're a consultant looking for a tool that'll generates timesheets for clients, Timeless Time and Expense is pretty good.  It costs $42.99, and can be found at

I'm just a satisfied customer; I have no interest in the company other than that I'd like it to stay around.

Hardware Guy
Thursday, April 3, 2003

I think timesheets can have the benefits that people here are claiming for them if they're done in a reasonably smart way.

For example, I used to work at a company which originally had a nice simple system--at the end of the week you filled in a form where you said how many hours you spent on each of the projects you were working on.  I'd guess that people mostly filled those in reasonably accurately, and so the company could probably get a good idea of how much work a given project took.

Then they switched to a web-based timesheet system, which I guess allowed some bean-counter to realize his fondest dream of getting lots of data, so we had to categorize our work into one of > 100 categories--how much time spent on design, writing unit tests, implementing unit tests, running unit tests, writing new code, fixing old code, bug fixing, integration, integration tests, and so on.

I have a tough time believeing (from talking to various folks there, not just my own experience) that they got anything but fiction from this system.  It could take an hour to fill in the damn timehseet alone.  (There were five different categories for vacations!)

Thursday, April 3, 2003

"At the beginning of a project, I work with dev leads to plan project time. We decide that feature x requires 3 days of dev time by Alice. Three weeks later Alice has finished feature x. I need to know that the dev lead and I were underestimating Alice's time by 80%, so I can get better at estimating how long it takes to do a feature with the complexity of x."

I don't want anyone else guessing how long it's going to take me to complete feature x.  Let me make the estimate, and accept the consequences if it's wrong.  I'll either make a better estimate next time, or, after a few horrible estimates, you'll learn to multiply my estimates by 70%, 120%, whatever.

Also, when I give an estimate, it's in ideal time.  Eight hours per day, five days per week.  If you want a schedule, tell me how many hours per day (or week) I am allocated to work on feature x.  Then I will give you a calendar schedule that tells you when I expect to be finished.  (Hopefully you will make the schedule yourself though.  I hate scheduling.)

I will also tell you how accurate my estimate is.  If you give me a day to estimate feature x, my estimate will be less accurate than if you give me three days.  Your choice.

When I begin work, I will use a timesheet to track my time.  This will tell you whether I'm spending the time allocated on feature x, or on helping Bob debug feature t.  If I decided to help Bob, I take the hit, and try to make up the time.  If you told me to help Bob, you take the hit, because you decided to reallocate my time.  (Which may be perfectly legitimate, for example if Bob and told you we can fix feature t in a day if I help, but if he has to do it himself it will probably take five days.)

If I lose a day because someone hosed the CVS repository and it had to be restored from backup, I will report that.  Not to blame the poor guy who goofed up, but to show the impact on the schedule.

And that's how I like to do things. :)


Thursday, April 3, 2003

One system I thought would always be useful is if the manager filled out people's timesheets, and the had the people sign them. That way

1. The task is shifted to the person who is supposed to handle these things

2. The manager is forced to think about how he is spending his resources

3. For a time sheet to get signed at least two people and possibly the two most important people to the process would have to agree on how time is spent, i.e devloper > what do you mean it took 30 minutes to install oracle

the artist formerly known as prince
Thursday, April 3, 2003

Among the timesheet management software out there, there's one called Timesheet.

I do *not* recommend it. I repeat: *not* (as in the report tool which name should not be spoken)

My former employer installed it and even managed to upgrade it, in spite of all protests. We nicknamed it "Timesh*t". Says it all.

Thomas Eyde
Thursday, April 3, 2003

I don't really like timesheets that much as my office manager and others use them as an excuse to tell me off all the time.

The best name I have heard suggested for a timesheet system was System Hours Insertion Tool (thought up by one of the programmers.)


Thursday, April 3, 2003

The book pepoleware has a chapter named:


In other words, many managers view timesheets  and software metrics like UFOs.

It can’t be measured, so why bother? Of course, many baseball mangers used to think that way also! Those baseball teams that adopted stats stared to beat the brains out of the teams that did not.

The same is happening in those software firms that use metrics. They run circles around ones that don’t.

The chapter in peopleware of course quotes what is called Glib’s law:


Anything you need to quantify can be measured in some way that is superior to not measuring it a all”


In other words, some kinds of measurement is superior to none. The other thing of course without some types of measurement, one cannot improve. I gave the example of baseball, but the same really applies to software. How can any team of developers even KNOW they are improving without some type of measurement?  How can a team of developers even know that they are good? It is like those teachers in school that propose to remove exams and all testing! When you start to put this whole thing into perspective, it almost becomes humorous. No one in their right minds would purpose that we remove exams and testing of students. Yet, many educators actually do, and have proposed this very concept.

Not measuring in business world is just as bad, or even worse then those messed up educators. Yet, many propose to do exact same thing the business world.

Having no feedback or numbers means that everyone is taking a guess as to where they stand. The excellent example to quote for the book peopleware is:


“Suppose the measuring came in to tell you that your productivity was in the top five percent of organizations doing your kind of work.  You’d be pleased. You’d would wonder around the halls with a secret smile , thinking warm thoughts about your people: “I suspected they were pretty good, but this is terrific news”

Ooops. The measurers have just come back to tell you that they must have been holding the graph upside down when they gave you the first report”. You're actually at the bottom 5 percent” Now your day is ruined. You find yourself thinking, “I might have known it all along. Who could expect to get any work done with turkeys like these on the staff? ”

In one case you are ecstatic, in the other you are despondent.



The above sums this up. You don’t have clue, and if you don’t have a clue you are running blind. The fact that you can be surprised EITHER WAY is the whole point here!

In school we use tests and marks. In the software industry, we use software metrics, and that means some form of time keeping.

Should a company keep track of the number of bugs? Heck, how long did it take us to learn to track defects in manufacturing? Managers scoffed at use of statistics and quality control tracking. Today, you would be laughed at for ignoring good information.

Of couse, people ware also warns that how the tracking information will make, or break the success. If that info is used by managers to put down developers, the whole thing will be a disastor.

Many software firms can output 10 times what other software firms can do. And further, they have the numbers to back this fact up. Does your software team have those numbers? How many blind computer mice do you have on your team?

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Friday, April 4, 2003

Metrics are good, the right metrics.

If you measure progress, obstacles and morale then, if you know the team and the team is experienced then you know whether its doing less well or not.

If you use timesheets as the criteria for billing then your clients are paying for your errors, mistakes, confusions and accidents, as well as whatever real work takes place.

Unless you code it so precisely that these elements are excluded, but then are they?  How tempting is it to put down a broken CVS (which the client isn't going to understand) as development?

If people are finding it difficult to estimate how long something will take and therefore express work in hours and bill in hours then why should they be any better at categorising what they actually did?

It doesn't take that long to get a feel for how long something should take, if there are unknowns then you cost them as unknowns, that is you define what you will do and you bill for that.

In the twelve or so years I've run my own ship I can count on one hand the number of hourly billed pieces of work that were about deliverables,  Consultancy time yes, my actual time spent on their actual work.

But if I'm delivering a definable 'thing' then I give them a price and we agree what that price relates to.

Not using timesheets doesn't mean you don't measure, you just use measurements that make sense of the process and the costs. 

Simon Lucy
Friday, April 4, 2003

I have seen useful applications of timesheets as well as bad applications of timesheets. Reading this whole thread, I feel that they aren't 100% bad nor 100% good - it comes down to how they're applied and how easy they are to maintain.

Joel Goodwin
Saturday, April 5, 2003

I have seen timesheeting done right, and timesheeting horribly wrong. In the latter case it leads to timecheating.

If you limit the timesheet coding to say 5 items, including meetings and stuff and leave a textfield for the developer to add comments you will be all set.

DEV        flux capacitor code              1
MEETING Meeting Libyans                  1
DEV        Time circuit code                  6

This is OK in my book; I have also seen horrible beyond belief coding with a project having say 10 work areas and
40 sub codes each in those 10 areas. This level of detail will result in total distress and the timesheet will look like this:

PROBLEMS                                            8
PROBLEMS                                            8
PROBLEMS                                            8

which is totally unhelpful and wasted both for the developers and project managers. Those project managers insisting on an absurd level of detail will usually only use one code themselves and can't understand why the other team members bitch about reporting on their timesheets.


Monday, April 7, 2003

*  Recent Topics

*  Fog Creek Home