When Should You Start Project Overtime?
When Should You Start Project Overtime?
Many managers believe that overtime, even extended overtime is a good thing, and will help a project make progress. However, most technical people who try to work more than two weeks of overtime make huge numbers of mistakes. Often, they don't realize the mistakes and have already wasted a lot of time and money.
I'm not a fan of project overtime. Too often, project staff start working overtime too early in the project, so they don't have enough energy left for the too-frequently inevitable sprint at the end.
If you, or other members of your project team didn't estimate well, if rework took longer than you expected, or if you acceded to a request that you squeeze a few more requirements into the project, then you or some other members of your team will need to put in some overtime.
Elise is working on a project that has met most of its milestones throughout the project. At the end of the project, during final system test, some of the developers took some shortcuts with defect fixing, so the rework took a little longer than planned. The project manager realized what was happening, and helped guide the project back on track. However, for the last four weeks of the project, the project manager asked Elise and the rest of the testers to work overtime to continue to verify fixes and create regression tests.
For the first two weeks, Elise and the other testers made progress, working about eleven hours a day, six days a week. By the third week, the testers were down to ten hours a day, five days a week. For the fourth week, Elise and the testers were too tired to work more than eight hours a day. They made the project release date with a successful release.
In contrast, Louisa started working overtime on her project about two months into a ten-month project. At first, the overtime was insidious-a developer asked her to verify a fix at 5:30 p.m., so she stayed late to finish the verification. At about the third month, the project manager realized the project was behind, and asked everyone to start working ten hours a day. Louisa frequently worked more than ten hours a day, because the developers would check in fixes at 7 p.m., and want to know if the fix was verified when they arrived at work in the morning.
By the fifth month, progress slowed dramatically on Louisa's project. The developers were checking in bad fixes, fixes that either broke something else, or didn't fix the problem. Because they were behind, the project manager chose to stop peer reviews, in hopes of making progress. Sixteen months into the project, the project manager was fired, the project declared done, and they started the next release, already behind.
The months and months of overtime fatigued the team. They started making more mistakes because they were tired. Instead of gaining schedule, they lost it. These long months of overtime killed the project and caused the dismissal of the project manager.
Many managers believe that overtime, even extended overtime is a good thing, and will help a project make progress. That has not been my experience. I find that I can maintain about two weeks of overtime before I'm too tired to put in a full day's worth of work. Maybe you can work more overtime, but most of the technical people I've seen who try to work more than two weeks of overtime make huge numbers of mistakes, mistakes they don't realize they're making until long after they've fixed the problems. If you think you need project overtime to make time up on a project, ask yourself these questions:
Am I within two to four weeks of the end of the project or a specific deadline such as a demo or tradeshow?
If not, don't bother with overtime; you won't meet the deadline. It's time to replan the project and change the project practices.
Am I working later than other people on the project?
If so, is that appropriate, or are their requests for me to work later making it easier on them and harder on me? Is there a way to accommodate their requests? Louisa's developers had a reasonable want-to verify their fixed problems-but the cost of verifying fixes late at night was too high for Louisa.
Am I working overtime because I don't think the other people on the project are pulling their weight?
If you're taking care of other people's work, you will always work too much overtime and your work will suffer. Your job is to do your job the best you know how, not to also perform Roberta's, Samantha's, or Alice's job. The consequences of performing more than your work are numerous. Some common problems are: the manager thinks everyone is performing up to par, and the other people will try to pawn their work off on you.
Project overtime may be a reasonable solution to the problem of meeting the project deadline, as long as the overtime is of short duration and there's a respite afterwards. If you're faced with a request for overtime before the end of the project, you can say, "I want to help the project as much as possible." Follow that up with some questions or requests:
"Is this a short sprint to an intermediate milestone, or are you asking me to commit to overtime for the entire rest of the project?"
Decide if either of these actions fit for you.
"Can we also change some development (or testing practices)? I've been thinking about peer reviews, and I think that will help the developers prevent more problems from entering the build."
If you have been thinking about a particular practice, such as peer review, more frequent builds, or different testing practices, now is the time to discuss it. The project manager is probably desperate for a solution.
"Can you estimate our project progress every day, so we can see how much progress we're making?
The more clear our project progress is, the more I'll see where to put my efforts."
If you're faced with imminent overtime, or you're already putting in long hours, think about whether it makes sense to do so. The more overtime you rack up in the early part of the project, the less capability you have to do more work at the end.
If overtime is necessary, consider whether your project team should continue doing more of the same, or if it's time to change development, testing, or project management practices. Overtime is your last project weapon to meet the deadline. Use it wisely.
Acknowledgements: I thank Esther Derby and Dwayne Phillips for their review of this article.
Further Reading
For more data about overtime and the problems it causes in software organizations, see chapter 19 in the book IT Measurement: Practical Advice from the Experts, edited by the International Function Point Users Group, Addison-Wesley, 2002. Fellner's paper explains that when overtime decreases, productivity increases.
Comments
#1 Submitted by Lyn Leffler on Fri, 08/15/2003 - 6:15pm.
I was one of the first of many people that quit working, yes even with the lousy economy, for a company that required that you work 60-70 hour a weeks without OT pay. After a year and no change in sight, management kept saying it would ease off, I had enough. My family, friends and health suffered. What I find interesting is the people that were left behind were the ones that didn't have the experience to do the job. I looked for 3 weeks and had another job, not as much but close to the same pay and the hours are more conducive to having a life. Look at it this way if you are a salary employee and you get $70,000 a year working 60 hours a week you are making $22.43 an hour instead of $33.65 an hour for 40 hours. I understand that there are times when you have to work overtime but not 100%. The problem I see is that as more and more companies are tightening their belts they are going to require their employees to work mor overtime hours without pay.
#2 Submitted by Bing Fang on Tue, 08/12/2003 - 5:08pm.
Overtime working happens in almost all software projects. To some persons 2 weeks will be work able, to some others maybe 4 weeks. It is true that people tends to make more mistakes under high presure and fatigable condition. It is not fair to due all these mistakes to overtime working. There are still many other reasons may lead project fail such as lack of process, design documentations, skilled people, communications etc. Not all overtime working will do harm to the progress. If the whole team have clear vision/goal and have passion on what they are doing, team member will be more willing to put more efforts, even their own time.
#3 Submitted by Gene Fellner on Thu, 07/24/2003 - 6:40pm.
Thanks, Johanna, for your kind words about my paper. Here's a brief summary of some of its points… This very evening, in cubicles all over America, software developers will be working long past their quitting time in desperate attempts to bring projects in on time and within budget - directly beneath placards bearing the slogan: "Work Smarter, Not Harder." The 40-hour average work week, which became standard after World War II, has now been stretched to 49 hours, nearly the same as at the turn of the previous century. [Jon's carbon-dating of the 72-hour week is off by a whole century. President Martin Van Buren established a 60-hour week for federal employees in 1840.] This reversal of half a century of achievements by organized labor is particularly evident in IT, the industry which ironically promised to make everyone's life easier. The ubiquitous workstation is at the center of a hurricane of chaos and inefficiency in which all IT staff members and many end users are expected to be experts at everything from performing their own clerical tasks to troubleshooting their own software, and no one, not even the workers themselves, have a clear idea of their total workload. The willingness to work overtime - which is rarely reported and almost never compensated - is traditionally ascribed to the so-called American work ethic. But studies reveal far less noble motives, including anxiety over not being perceived as a team player and outright avoidance of the responsibility of raising one's own children. The defect-ridden software delivered by workers with exhaustion-impaired cognitive functions becomes a death spiral of its own cause and effect. More developers are diverted into software repair, leaving a smaller pool behind to be worked even harder and deliver even lower-quality softare. Sixty percent of America's software developers are tied up in maintenance, and one third of the remaining forty percent are hard at work on projects that will be cancelled before completion. More rigorous yet extremely inexpensive and cost-effective project management practices, such as risk analysis and requirements reviews, could salvage many of these wasted human resources and allow everyone to go home on time. Instead we find the family unit breaking down due to the stress of job burnout and chronic absence of adults from the home, and consumer markets being skewed by a new category of "necessities," such as extra cars, fourteen-hour daycare, and a steady diet of convenience food, that take a toll on the physical and emotional health of the whole family… There are signs of hope, however. Recruiters report that an increasing number of job-seekers refuse to interview for the highly paid positions in high-pressure "skunk works," preferring the job security offered by a company with a business plan that extends beyond the next quarter and skillful managers who do not need to overwork their staff. Investors have no confidence in companies that meet their quarterly goals by reviving the draconian management practices of the Victorian era. One high-tech firm began experimenting with a 32-hour week and found that its defect rate dropped so precipitously that net productivity actually increased, as did customer satisfaction… Adoption of the Key Process Areas of the Software Engineering Institute's Capability Maturity Model can help halt the epidemic of unreported and unpaid overtime that threatens to drag American industry down while its more enlightened European competitors send their staff home before dark and don't allow them to skip their four-week vacations. Risk analysis will put an end to dead-end projects. Defect tracking will expose the practice of suboptimization - cutting corners during development, which only represents ten percent of the total life cycle cost of a system, while allowing maintenance and enhancement costs to spiral out of control. More rigorous time accounting will uncover the fraudulent productivity claims of managers who run a two-shift shop with a one-shift staff… To "work smarter, not harder," will result in IT organizations, their staff, and their families enjoying better economic, physical, and emotional health.
#4 Submitted by Robert E. Lee on Tue, 07/22/2003 - 5:55pm.
Jon observes that "Two generations ago work weeks were longer than 40 hours. As I recall 10 to 12 hours a day 6 days a week were the norm." Peter Drucker points out that the Baby Boomer generation is the first in American history to reach retirement age healthy enough to enjoy retirement. The working conditions prior to WW II led to injury through inattention after too many hours. Farm work, mining, and other active jobs can lead to accidents that progressively cripple one. Working exhausting hours can lead to falling asleep at the wheel on the way home from work.I don't view those as "golden oldies" to long for!Bob Lee
#5 Submitted by Brad Chodos-Irvine on Tue, 07/22/2003 - 3:42pm.
After 14 years of working as a software test engineer and testing manager, I'm amazed that this topic continues to come up. I've worked at large corporations, and at small start-ups and it is surprising how easily one can fall into this trap. It's never done on purpose, but a series of mistakes always leads the same end: long hours of overtime for the test group (and likely developers beforehand) and a "slipped" schedule. Despite the seeming advantage of cutting corners, we all know that it doesn't work. Writing product specs, reviewing them, developers writing work estimates and reviewing them, testers writing test specs and reviewing them, developers doing code reviews of fixes... all of these things take time but in the end almost always allow a clearer, more realistic picture of how long a project will take. Sadly, it is too easy to be overwhelmed with all the side projects that come along, and skimp on these steps. We know it doesn't work - but we wind up doing it anyway...Thanks, Brad
#6 Submitted by on Tue, 07/22/2003 - 3:17pm.
Jon observes that "Two generations ago work weeks were longer than 40 hours. As I recall 10 to 12 hours a day 6 days a week were the norm."If you look a little earlier in history, you'll find that slavery was an option too. Western society gave that stuff up because we decided that innovations like freedom, sleep, and the weekend were economically beneficial. It wasn't just the workers that decided it, either; owners and managers were part of the decision too. When Jon suggests that "when to stop overtime is an individual thing", I agree--as long as the decision to extend the work day is your own, rather than imposed on you by a manager. Note that I specify "extend" here; I think a manager is perfectly within his rights to close the shop earlier than some employees might want.My experience is that people have about five hours a day of real, effective work in them over an eight-hour workday. In a twelve-hour workday, you can stretch the productive part to six, maybe seven hours, but there is a law of diminishing returns. I contend that the better approach, more often, is to figure out ways to make the eight-hour workday more productive. If I were looking for ways to get more out of people during a day, I'd foster more collaboration and review, rather than getting people to work longer hours making mistakes in private.
#7 Submitted by Bill Boling on Tue, 07/22/2003 - 1:57pm.
For me, overtime required in a Project is an indication of poor planning and should not be tolerated. A Project is planned, good planners will build in time for problems. As well as with change control in place, any change to the Project, such as new requirements, will allow the project time to be adjusted. As an employer, you hire workers normally on a 40 hour week or 80 hour pay period. Even salaried, workers in general are hired on this bases, with the expectation that on occasion, they may need to work late or come in early. However, this should be the exception not the rule. The best employee is a happy one. A happy employee is one that works hard for 8 hours and goes home to he/her family and friends. There are no employees that look foreward to spending more time at work than they have too.So how about an article on, "how to prevent overtime in a project" or "how to limit overtime in a project". just some thoughs on the subject,williabo
#8 Submitted by Jon Hagar on Tue, 07/22/2003 - 12:13pm.
A question for me is what is over time. There is a legal definition, but in the past it was different? Two generations ago work weeks were longer than 40 hours. As I recall 10 to 12 hours a day 6 days a week were the norm. Also even today, most people working for themselves, work those kind of hours. And if you look at America work statistics, I seem to recall the average work weeks is something like 45 to 50 hours a week (meaning most people work OT). So maybe a good question is not if OT is bad and to be avoid because of things like mistakes, but how when OT is necessary, which it often seems to be, can we make it effective? The arguements against OT focus on mistakes, but I have seen only a few good studies on it, and I've not seen any out of the software/software test world. So when I find myself and my team working OT I watch for the mistakes or indications of "issues", and then I can take some actions, which will be different depending on situation. Sometimes a correction can be a simple as sitting and doing nothing for a few minutes or sending somebody home (including myself). So OT is largely a personal thing and a mental view, and there are an infinate number of actions on those fronts. So for me, you start OT when there is a GOOD need. When to stop is a very individual thing. And you many need many stops and starts on any given project and/or person.
#9 Submitted by Darryl Hurmi on Tue, 07/22/2003 - 11:33am.
I have worked on a project that management required the whole development team to work at least 50 hours a week for a year and if you worked over 60 you got payed overtime. A large percentage of the development team was present for 60 hours a week, but little extra work got done. I do not believe that overtime should ever be planned or paid. Everone needs time to think about their work and if your working overtime your not thinking about it your doing it. My best ideas come after a good nights sleep on the drive to work. If I don't get the sleep I don't get any ideas.
#10 Submitted by Arvind Padmanabhan on Tue, 07/22/2003 - 8:27am.
OT is needed at crucial junctures of the project. There willalways be a debate on Why OT arose, (Bad Estimation, Senior Management Fault, etc...). But, if we do not control the OT, the OT will control us. Our thinking cap will oose out. A very good article.
#11 Submitted by Gunasekarran Veer... on Mon, 07/21/2003 - 7:55pm.
Normally Project Plan is prepared by a Project Manager from the Develoment team where scant importance is given to the QA Process activities. QA Planning and Defect turn around time are not properly estimated. Everything goes smooth (possibly) till first round of test execution and when the Test engineer detects a critical bug with requirement implications, the turn around time for the bug fixed software increases since lot of correspondence and clarification emerges out of each cirtical bugs. I worked in a project in which all through the day the developers used to fix the bugs and release it to the test team at the end of the day requesting us to complete testing before next morning. Always QA is taken for a ride since it is considered to be a easy job by the 'Powerful' people.The release date will not be shifted as it affects multiple quarters. We were forced to stay almost 3 days in the office to test the system. You could imagine the produtivity of my engineers. If you work under pressure your can not get the best turnover from your work which is more important in our area.
#12 Submitted by Frank Patrick on Mon, 07/21/2003 - 11:21am.
OT is an addictive drug for projects...a little helps in the beginning, but the effect wears off, making the user feel s/he needs more and more. Nine times out of ten, more time (overtime) for individuals will not provide equivalently more time on the project that is driving it. In most project shops, there are so many distractions from non-project demands, from PM micro-management interference, and particularly from multi-tasking on other projects that the overtime will, at most, be spread too thin to provide meaningful advance of the project in question. In addition, in my experience, there are also so many bad assumptions in project dependency networks -- particularly about needing all of A before dependent task B can start -- or the "batching" of work -- or the assignment of resources -- that there is far more opportunity for accelerating the project by examining such assumptions than there is in killing people with extended OT.
#13 Submitted by Nancy Kramer on Thu, 07/31/2003 - 4:02pm.
Ah, but we enter the world of contracting. And some very reputable contracting firms, when presented with a customer who will pay for it, will take the money and tell their consultants to do the customer's bidding. Wah, Wah, consultants get paid a lot -- well maybe. Fortunately, I'm a not-so-highly-paid consultant, so my customer doesn't ask I work horrendous hours. I do see this happening to others around me who are on different contracts. My hours spike, but it's in the last 2 weeks of the project, and it is to meet a specific goal. I see others around me working long hours and holidays, because that's what the customer will pay for. Their code is spaghetti and, one simple change to the interface, functionality mysteriously disappears and there is no traceabiltiy to get it back. WOW what a nightmare!
#14 Submitted by Peter Clark on Wed, 07/23/2003 - 12:36pm.
I was watching the Tour de France last night. Lance Armstrong was sprinting up-hill (stay with me, I am going somewhere with this). I noticed that his sprinting technique involved getting up out of the saddle and going hard for a minute, followed by a minute or so of his more normal pace sitting in the saddle. Lance was clearly allowing his body to recover for a period after each period of extraordinary exertion.I think in performing overtime we need to follow Lance's model. He could proably have sprinted out of the saddle for five minutes straight, but at the end of that time period his legs would have been toast, and he would have lost ground to the pack. Applying this to overtime, I would recommend a week or two of overtime followed by a refractory period of one or two weeks before any additional overtime.There was an interesting article awhile back on sleep deprivation. It was discovered that cummulative sleep loss (one or two hours per night) was just as damaging as going without sleep continuously - if you lose two hours of sleep every night for a week you will be just as whacked out as if you had just spent an all-nighter. The relevance of this is that sleep is typically the area that people first attempt to scrimp on when being forced into overtime - the rest of their work/commitments outside the office doesn't go away, and the slack has to come from SOMEWHERE.Finally, your comments regarding doing overtime when it is still early enough in the project to have an effect were dead on. Unfortunately, project and line managers get as behind as everyone else, and tracking and risk management seem to be the first things they throw off the back of the sleigh when the crisis wolves come howling. This is precisely the information that they need to anticipate and correct projects before they turn into calamities.
#15 Submitted by Ed Weller on Fri, 07/25/2003 - 3:22pm.
Years ago I was assessing a company and asked the usual question about overtime (one of the ways to check project estimating - regardless of what people say about estimating accuracy, if they work large amounts of OT, the estimates are wrong). The answer I got from the project managers was one of the measures of their performance was "how many hours of OT we sucked out of the development teams" (the more, the higher your rating.The problem with "overtime" is that it appears to be free. If overtime was not free, then there would be less incentive to use it as a solution to inadequate staffing or unrealistic schedules. How you set t up so that it is "t free" is a good question, however.I worked on a project years ago where we knew we were understaffed. Solution: start working 50 hr week, for the next 3 years! Too bad it was a 6 year project. About 3 years in, I wised up (?) and accepted a promotion to management (test manager) - among other reasons was to stop working overtime. One of the things I did was consistently try to get my people out of the building on time and work less OT. Not entirely successful, as peer pressure from the development side kept my testers in the building. To answer Johanna's question in the title of her article, OT should be reserved strictly as a contingency for risk management, and for very short durations at key project schedules (like 1-2 weeks before delivery). Also for production problems.My favorite story was the PM who came to me bemoaning the fact management had decreed "work Saturdays" to catch up. At the time the project was 13 weeks (65 days) late. Delivery was 6 months away. That was 26 Saturdays. Why can't some people do simple arithmetic?Ed