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.