Under which conditions is it acceptable to push my team to do overtime work? Once I have pushed my team to do overtime work, how do I factor the added risks and costs associated with the push into my project plan?
asked Feb 8, 2011 at 3:24
Add a comment
|
3 Answers
Overtime happens. I am a salaried employee and don't get overtime pay. I would not advocate pushing your team into overtime, routinely but even if you have defined reasonable goals, you may find that you have to work some overtime. If your team is working overtime frequently, the project schedule is probably unrealistic and you as the PM need to revisit that.
Account for every hour worked. Use your standard timekeeping practices. Don't think you'll be able to keep track of "normal" work in your timekeeping system and OT somewhere else. If you don't know how much work went into today's project, eventually you will have no idea what it actually costs your team to produce anything. In small companies expect push-back from finance. Accounting for all the hours, but not charging for them all make finance's job more difficult because employees who work overtime are going to have to be billed at a lower hourly rate when it's time to bill the customer.
Things to consider:
- If you are constantly pushing for overtime, you are probably going to impact team morale. This will impact productivity, but I don't know how you could quantify that number. Excessive obligated overtime becomes a weight that will eventually crush your team.
- If you let this spiral out of control and you someday decide to try to charge you customer the true cost of getting things done, you'll find they balk at the new price. What is the risk that you might fail to win future contracts unless you continue to bake-in an artificially low price based on (ever increasing) uncompensated overtime rates?
- If you do need to push a team into overtime, throw a party when you're done. If everyone worked hard & you got your product out the door, then a party is a good way to let everyone know they were an important part of "making it happen" and the company values their contribution.
- If you need to plan for recurring overtime, you should integrate it into your formal reward system. I would avoid cash rewards. There are things programmers want more than money.
If you are running a 'scrum-like' team, then the team itself made a commitment to a certain amount of work. The team should try to get it done, and in my experience most teams that have themselves committed to a bunch of work will go to great lengths to honor the commitment. Then they use that as a lesson-learned for the next phase & they (hopefully) don't commit to so much work.
-
1+1 for making it special, and for "creative compensation". Commented Feb 8, 2011 at 5:51
Overtime is evil. No matter what. If a project manager considers overtime as a mechanism for solving his/her own mistakes he/she has to change his/her job.
Before pushing for overtime, it's important to determine if the success of the goal is really reachable. If the probability of success is low, then overtime may just unnecessarily waste time, energy, and resources.
If probability is too low, you'll have to answer the question yourself of whether or not it's acceptable to push for overtime. If the reward is great, then by all means, push. But if the reward isn't great, then the opportunity costs may prove to be more beneficial.
As for factoring the added risks and costs into the project plan, I'm not sure how to answer that part without more specific information.
