If the average developer spends 40 hours per week at the office, some research indicates that only about 30 of those hours are productive (Jones 1991). When that developer is asked to voluntarily work a moderate amount of overtime, say 10 percent, two things happen. First, the developer spends 4 more hours per week at the office, which by itself increases productive hours from 30 to 33, if the proportion of productive hours to work hours is held constant. Second, the developer attaches a greater sense of urgency to the job at hand and can often find ways to increase the number of hours worked per day from 6 to 6.5 or more. Thus, overall, the productive hours have increased from 30 to 35.5, which is an 18-percent increase in output for a 10-percent increase in hours spent at the office.

The bottom line on Voluntary Overtime is that a slight increase in hours worked per week beyond the nominal, say 10 to 20 percent, will usually result in a disproportionately large increase in productivity.

For projects that start to use Voluntary Overtime during construction or testing, overtime can help to shorten a project's overall schedule by 10 or 15 percent (Jones 1991), but beyond that the motivational penalties come into play and additional schedule reductions through overtime are not possible.

Unfortunately for many organizations, Voluntary Overtime is a best practice that is already in widespread use or is already preempted by excessive, mandatory overtime. The average developer in the U.S. already works 48 to 50 hours per week (Jones 1991, Krantz 1995). Similar situations exist in Canada and Japan. This situation raises the interesting possibility that the average organization might actually increase total output by reducing overtime below its current level.