So it goes like this: we are keeping track of tasks using Redmine. We log time spent doing tasks, but at the end of the week if we add up all the time spent at those tasks there is no way a person has spent 40hs working. I think that's correct because offices have overhead (reading emails, politics, coffee, distractions). What would be a normal productive time vs total time spent ratio? Other areas in the organization just measure time spent in the office (with the rfid badges that open the door) but we don't like that approach and we are trying to convince Auditing to measure us using redmine instead.

  • 8
    Solutions to complex problems pop up in my head often while I'm commuting from work to home, in the supermarket or sometimes even when I'm in bed trying to catch sleep. Where should I write those productive hours (moments)?
    – Pieter B
    Dec 12, 2012 at 14:04
  • 3
    ((office hours) - (15 minutes) x (number of interruptions)) / (office hours)
    – Giorgio
    Dec 12, 2012 at 18:51
  • 3
    Be careful what you wish for. Logging time spent in office is not so invasive-- kind of like a head count. Tools like redmine give very fine-grained information. Do you really want to trust the judgement of an auditor to evaluate every little thing you spend time on? These tools are great for nitty-gritty project management. In the hands of an auditor, it could get very onerous.
    – Angelo
    Jan 2, 2013 at 19:57
  • 2
    What's the audit for and what is the outcome of reviewing the metrics? I understand your desire to avoid RFID tracking, but you could be out of the frying pan into the fire if you offer a tool used for task productivity to auditors with a simplistic conversion metric - given how auditors use numbers like this, it could go very, very wrong. Jan 2, 2013 at 20:21
  • 1
    sane people realize 75% productivity rate is usually about max. Many manager believe 100% is real. But even at 75% keep in mind that a lot of tasks one does aren't really productive to begin with (such as filling out time sheets)
    – DA.
    Jan 2, 2013 at 22:56

5 Answers 5


On most project management courses I have been on there's a general assumption of a ~6 hour "productive" day for operational purposes, with the rest being classed as overhead and general administration.

A large part of our organisation time-writes for billing purposes, and has a target "chargable time" utilisation rate of 80%; we operate a standard 7.6 hour working day this is measured against which gives a similar figure.

This figure is about average for a technical consultancy role - I have seen some professions like lawyers quoted as being higher, and others like engineers a bit lower.

The overhead involved in "switching" tasks is quite high, and so while 80% is an average, someone with a highly "fragemented" role would be less if measured accurately, perhaps 60%; this generally applies to anyone with a management role who has to interact with staff above and below, or clients.


At my last job we scheduled work based on an "ideal hours" concept; hours spent heads-down, flat-out coding new parts of the project (which from an external viewpoint is "forward progress" aka productivity). An 8-hour day has 5 to 6 ideal hours; the rest of this time is spent in meetings, on phone calls, dealing with technical problems, fixing bugs in previous development, refactoring code and paying off other technical debt, etc. All of it's necessary, none of it moves the project forward. In practice, one calendar day may be spent completely heads-down coding and thus may have 8 ideal hours, while the next day may be spent primarily in client meetings and may have zero ideal hours spent coding. It averages out.

I will echo other answers and say that your company is unique even among others in the same industry or niche, and thus the ratio of "ideal" to working hours is going to be different. It's usually better to estimate in terms of "programmer-days". Whatever the ideal-to-working ratio is, how many calendar days should a developer be expected to take to finish a work item, given past performance and the estimated complexity of the task? The overwhelming majority of schedulable work items will take more than one programmer-day to complete. Anything smaller than about half a programmer-day can usually be shoehorned in wherever it fits, provided it doesn't turn into the following:

An eight-panel Dilbert comic. The first panel is an employee telling the boss "Our budget won't cover all of the product development." The second panel continues with him saying "We can only do two-thirds of the features for that amount." The third panel is the boss saying "Reduce the scope of the project by one-third." and the employee saying "okay". The fourth panel is the boss saying "But... theoretically..." The fifth panel is the employee thinking "No... Dear lord, no..." as he walks away from the boss. The sixth panel is the boss out of view saying "If I later give you a change request to add one feature, could you you do it for the same budget" and the employee saying "One? Sure." The seventh panel has a text panel saying "Data goes in, management comes out" with the words "One? Sure" going into the boss's ear and "changes are free" coming out of the other ear. The eighth panel is the employee sitting working with an enormous stack of papers beside him, and someone holding a large pile of papers coming in and saying "Where do I put the change requests?"

  • 2
    Automatic +1 for Dilbert...
    – GuyM
    Dec 12, 2012 at 19:03

I honestly don't know if you'll find a standard that fits your workplace and culture. No two departments are identical even if they are both the same (i.e. IT, HR, ...) across different companies/locations.

Use your tool to learn your baseline. From that you can make informed decisions on what you can do to improve the ratio in your situation.

  • @RhysW I wouldn't be surprised at all, I often wake up during the middle of the night with a solution to complex problem. My point is that you don't have any information without the baseline so can't say if you're overall productive or not.
    – Steve
    Dec 12, 2012 at 19:00

It's totally wrong to start with some ideal ratio and try getting people to do that ratio. The amount of politics, distractions and the efficiency in meetings varies widely. I've been in assignments with say 30min productive work a day (because of excessive politics and multiple involved teams) - to perhaps 7-8h/ day.

Some people in offices tend to get more (task related or not) questions and might be a lot more distracted - but it can be productive for team as a whole.

Why not turn this up side down instead? Enhance the ratio instead, remove distractions etc.

Like other people said, the best productivity might not even come at work - solutions to hard solved problems may well come during vacation at a relaxed beach or when driving to work. The real "Aha" experience. Actually, today I "solved" a critical concurrency issue my client have been struggling for a long time with while snowboarding.

If you intend to use these figures for something - people will probably put up some overhead time on "productive tasks" anyway - because it is expected.


According to recent studies, an average worker is productive only 3 hours a day This time may vary according to your expertise.

  • @SolarMike Not sure why for journalists but another topic claim that developers have 3.5 - 4h maximum productive work per day. Jun 10, 2020 at 9:16

You must log in to answer this question.