I find myself regularly expressing project schedules using two terms. I have made up one of them and it is clear to my listeners what I mean. However, I suspect that more common terms exist for these items.

The terms are:

  • Working hours - This is a statement of actual or estimated working hours. For example a "40 hour" project. I think the common term for this is "man hours"
  • Calendar time - This is how long a project takes in terms of dates. As in, "I'll have it by next Tuesday". I do not know the term for this.

These terms are applied in the context of, "This is a 20 hour task and based on my schedule it will be completed in one week.". This shows the effort involved as well as the scheduling aspect.

What are the correct or widely used terms for these concepts?

To clarify - I am NOT asking about the conversion and application of man-hours vs. calendar-time. I simply want to make sure I am using the right nouns for those two concepts.

  • 4
    Those are common terms. And a major misconception is a calendar week = man week. Any job has administrative overhead
    – paparazzo
    Jun 20 '16 at 18:52
  • I often use "wall-clock time" to refer to "calendar time." Jun 20 '16 at 19:35
  • We usually use the terms man-hours and project due date. Be sure when figuring the due date to not allow 8 or more hours per person in per day in work hours. YOu need to only allow 80% to account for leave (both planned and unexepected like bereavement leave), administrativcee work, unavoidable delay, and people being pulled off temporearil;y for other projects or production issues or required HR trainiendg etc.
    – HLGEM
    Jun 20 '16 at 20:31
  • 1
    man-hours is very common. see: en.wikipedia.org/wiki/Man-hour Jun 20 '16 at 20:38
  • Instead of "calendar time" I would suggest "Due date" for what you described.
    – Brandin
    Jun 20 '16 at 23:33

Man hours are correct for your working hours however be careful that these are multiplied by the number of people working. For example a team of 5 working for an 8 hour day on a project contributes 40 man hours.

Duration or wrap up date can be used to discuss your calendar time depending on context.

Taking your example "This is a 20 man hour task and based on my schedule it will have a one week duration" sounds quite natural to me but "This is a 20 man hour task and based on my schedule our wrap up date is projected to be June 28th" would also be fine.

  • You won't get 40 hours actual work with 5 people working an 8 hour day...
    – HorusKol
    Jun 21 '16 at 14:15
  • 1
    @HorusKol Was just about to comment on your answer. The preferred method when I studied this in university was that your task time was padded to included 20-25% of non-focused work. So a 40 man hour estimate would be 32-34 hours of active work and 6-8 hours of breaks/meetings/random paperwork.
    – Myles
    Jun 21 '16 at 14:18
  • 1
    I guess it comes to the same result - but I prefer to not pad a task time (because then I know a 1 hour task will take 1 hour), and simply acknowledge that 1/3 of a working day will not be "on-task".
    – HorusKol
    Jun 21 '16 at 23:30

Man-hours is correct for the amount of effort required by one worker.

The problem comes with conversion to calendar time for deadlines.

It is very easy to think that a 40-hour project can be done in one work by a worker who is contract for 8-hour days. But then that worker has to get a a couple of coffees, probably go to the toilet a few times, and take a break (even if just sitting as his desk) every hour or so. Not to mention people coming in with questions, email, setting up appointments, and meetings (related and unrelated). Then there's overhead whenever you start adding more developers to a project team, since they have to communicate with each other about what they're doing.

Plus, there's typically other work involved around the project that doesn't get included in the working time estimate.

All this means is that you can't divide by 8 hours to get the calendar time for a project.

After a bit of trial and error over the years, I've found assuming 5 hours of on-task activity per day gives a pretty fair estimate (we work 7.5 hour days [8 hours if you include a lunch break]).

So, a 40-hour project will be completed in 8 days by one person.


What you are describing is the different terminology between effort and schedule. As others have answered, schedule has to incorporate some level of overhead, as well as individual leave arrangements, public holidays, staff rolling off/on etc...

There are a number of variants on this, and probably the most prevalent are already in your question, but in the software development community common terms for effort are:

  • ideal hours
  • story points
  • effort hours
  • estimated effort (hours)

...whilst schedules either directly refer to the calendar, or use terms like working days.


Work hours are for time to complete task or project by each team or individual. Calendar hours or time is for the whole combined hours of all individuals and processes needed over a period of time to complete more than one project to reach a goal by the end of a predefined cycle or timeline. I.e. Quarterly or Annual or reporting. The shortest way to put this is Calendar hours are the combined hours of full time and near full time employees each month of the previous year then averaged for the year to determine "service hours" I searched under Calendar hours/reporting for applicable large employers. This formula is also used to determine employee benefits or employer responsibility and a similar definition is used to determine students credit hours or even professional qualifications.

  • 1
    is this merely your opinion or you can back it up somehow?
    – gnat
    Mar 2 '17 at 13:48
  • I don't have definitive proof. This is similar to a method That I used myself in construction.
    – C.E.B
    Mar 2 '17 at 13:55

Not the answer you're looking for? Browse other questions tagged .