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