«    »

Two Types of Time in Project Schedules

My article on Understanding Project Schedules discussed four factors of project schedules: time, resources, scope, and quality. Time is often the factor of greatest interest to project stakeholders such as customers or management. They often ask when the project will be finished. I refer to this as elapsed time - the passage of days on the calendar. Stakeholders can also want to know the project's cost, which largely depends on the amount of time project members work on the project. I refer to this as effort time, which I define as the number of hours one person must work to complete a task.

These two types of time are related - the larger the effort involved the longer it will take, all else being equal. But they measure different quantities, even though both are expressed in units of time. A common pitfall is to conflate the two. Developers often estimate their tasks in effort time, while project managers and customers are more concerned with elapsed time. The following story highlights this problem.

Project manager Mark comes by developer Dave's cubicle Monday morning to ask him how long it will take to complete the foo-bar feature. Dave figures there are about five days worth of work, so he tells Mark it will take a week. Mark tells Dave to start working on it and walks away thinking it will be done by next Monday. As the week passes, Dave makes good progress on the feature, but is nowhere near done by next Monday. When Mark comes by to verify that the foo-bar feature is finished, he is disappointed to hear that Dave isn't done. Dave defends himself by explaining that he spent time on other activities that left him with less time than he expected to work on the foo-bar feature. Tuesday he had a design session to go to. Wednesday was the regular team meeting, which took longer than normal. Thursday Tim the tester found a defect in the previous feature Dave had implemented, and it took Dave a few hours to fix the problem. Dave concludes by saying that as a result of these other tasks, he hasn't yet put in his full five days of work on the feature, and figures he will still achieve his original estimate.

What went wrong? Dave's estimate was in effort time, but Mark assumed it was in elapsed time. The root cause was a communication failure. Whenever I'm asked for an estimate, I always clarify whether elapsed time or effort time is wanted.

What if you have created your estimate in effort time, but have been asked when you'll be finished? How do you convert between effort and elapsed time? I'll start with effort time and present some formulas for converting to elapsed time. Effort time is assumed to be in units of hours of effort by one person, totaled for the task or project for which elapsed time is desired. A simplistic conversion formula is:

Elapsed time in calendar days = (total effort) * 1.4 / (number of hours worked per day * number of people)

This formula first converts the effort in hours to days of effort for the whole team, then converts that to elapsed time using the factor of 1.4, which is derived from 7 days in a week / 5 working days in a week. The final value can be used to determine a project completion date by adding it to the project's start date.

Here's an example. A project is estimated to have 160 hours worth of tasks. There are 2 developers each working 8 hour days. The elapsed time = 160 * 1.4 / (8 * 2) = 14 calendar days or 2 weeks.

Unfortunately, this simplistic formula will underestimate the actual elapsed time because it fails to account for several factors. The first factor is that the amount of time a person spends working on a project is always less than the amount of time spent at work. I call this the productivity level: the ratio or percentage of time spent working on the project versus the total time spent at work. The ideal is 100%. The practical maximum is about 95%, which means that out of a 40 hour work week, 2 hours a week are spent on overhead or administrative activities. Even for a developer dedicated to a single project, there are emails to process, meetings to attend, time reporting to attend to, communication with other developers, and other similar tasks that prevent them from obtaining 100% productivity. People assigned multiple responsibilities fare much worse. Overhead activities increase roughly linearly with ones responsibilities. For example, if you are involved with two projects instead of one then you likely have twice the number of emails to process and separate meetings for each project to attend. There is more task switching, and an increased likelihood of interruption since there are more people you are dealing with who may have need to communicate with you. In my experience, the productivity level in this case can fall to 75% or lower.

Another factor affecting elapsed time is that employees don't always work five days a week, especially for longer projects of several months duration or more. The simplistic formula's factor of 1.4 only accounts for weekends. There are also statutory holidays, sick days, vacation days, and training days to consider. We can calculate a new factor to include this other time off as follows. Start with 365 days in the year - 52*2 (weekends) - 10 (stat holidays) - 15 (3 weeks vacation) - 5 (sick days) - 1 (training) = 230 days worked in the year. The ratio 365 / 230 = 1.6.

Revising the simplistic formula to account for these additional factors results in a more accurate formula for calculating elapsed time from effort time:

Elapsed time in calendar days = (total effort) * 1.6 / (number of hours worked per day * number of people * average team productivity level)

Using our earlier example (160 hours of effort, 2 developers, 8 hour work day) assuming a 75% productivity level gives the following. Elapsed time = 160 * 1.6 / (2 * 8 * 0.75) = 21 days or roughly 4 weeks. This is twice as long as the result produced by the simplistic formula.

This revised formula is still only an approximation and could be further refined. For example, large teams have increased management and communication overhead that should be explicitly factored in. For multi-year projects turnover of project members becomes a significant factor. In my experience, however, the above formula is sufficient for modestly-sized software development projects - up to ten people working for no more than one year.

If you find this article helpful, please make a donation.

3 Comments on “Two Types of Time in Project Schedules”

  1. Mike Totman says:

    The concept has also been discussed by the Software Engineering Institute: http://www.sei.cmu.edu/tsp/

    They have an entire development process that focusses on “Task Hours” (time actually spent working on the task) in just the way you talk about. The company where I work has been using the system for a couple of years. We’re finding that a typical Senior Engineer can get between 10 and 15 task hours in during a typical 40h work week. Eye opening.

  2. Rob Williams says:

    I suggest that it would be useful to be precise about the difference between elapsed time and effort time: elapsed time has units of time (hours) while effort time has units of person-time (man-hours).

    Of course, we all know that you cannot speed up the effort simply by multiplying the people (adding people to a project makes it later).

    Also, many agile methodologies specifically track the ratio between elapsed time and effort time for a single individual, e.g. “velocity”. Actual messurement has tended to reveal a ratio of about 2.5-3.0, which corresponds roughly to the figures given in a previous comment.

    I have recently stumbled upon “Evidence-Based Scheduling” by Joel Spolsky, which I recommend that everyone read.

  3. Paras Jethwani says:

    Helpful article and nice follow-up comments

«    »