Use Overtime as a Last Resort

By Johanna Rothman.

Overtime is the last degree of flexibility in a project. Unfortunately, too many project managers and project staff use overtime as the first reaction when a project starts to miss the schedule.

Gene Fellner, in his article in Chapter 19 in the book “IT Measurement, P ractical Advice from the Experts,” edited by the International Function Point Users Group, Addison-Wesley, 2002, has several arguments against overtime. This one was the one that caught my eye:

“One plastics firm – a high-tech bastion of knowledge workers like IT – found that by shortening its work week to 32 hours and giving its employees more time to recharge their mental batteries, its defect and rework rate dropped so sharply that net productivity actually increased.”

I’ve certainly found that long periods of overtime create products with tremendous technical debt. That debt causes problems for the next project because the product is unstable, and the problems have to be fixed. Not only does the project staff have to perform new development, they have to fix as well.

So, your project is late. What can you do aside from start with overtime?

1. Ask how little you can do. Too many project start with grandiose plans, delivering a subset of those plans. If you start missing the schedule early in the project, ask how little you can do and still have a successful project.
2. Step back and look at what’s causing the slip. Are some people not meeting their deadlines? Maybe they need help with peer review of a design. Maybe they need help with peer review of code, to detect defects before the defects cause build problems or test problems.
3. Are people multi-tasking on too many separate pieces of work? The more people multi-task, the less time they spend on your project, so the project becomes late. The later the project becomes, the more you’re tempted to use overtime. But if people are multi-tasking on several projects, overtime makes the problem even worse. With overtime, they context-switch even more often. Make sure people are working on one project at a time.
4. Are people busy fixing problems from the last release? If so, stop development on this release, and fix for a while. Peer review all the fixes, so you know you have a solid code base to start development.
5. If you haven’t defined release criteria for your project, do it now. Maybe you can deliver what you’ve got. Maybe not, but at least you’ll know how late you really are.

If you’ve tried all that, and you’re within a couple of weeks of the end of the project, then a little overtime is probably okay. But take the overtime into account when you add up the person-hours you spent on the project, so you can improve your estimates for the next time.

If you’re near the beginning or in the middle of the project, don’t start with overtime. Replan the project, planning to release with fewer features.

Johanna Rothman can be reached at jr@jrothman.com. This article reprinted with permission from the Pragmatic Manager.