When Should You Start Project Overtime?

[article]
Summary:

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.

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03