Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

You've launched a large project at work, something that's been in progress and taken up large chunks of your life for more than 6 months. The post-launch triage is over. Tech support isn't calling you every hour because they don't know how to troubleshoot an issue. Your hours drop from 60+/wk to whatever is normal in your organization (which is hopefully less than 60+!).

How much time do you (or your team) need before the next large project begins?

I was asked this question at work and I think the ideal minimum is two weeks -- one week to clear your desk and inbox + one week to clear your head and remember what it's like to have a life outside of work.

I'd frankly acknowledge that just being asked this question is a huge boon to work/life balance. But I do think it's possible to go too long in between.

share|improve this question
9  
Enough time to figure out how not to work 60+ hours a week on the next project –  Aaron McIver Feb 9 '11 at 19:28
    
If your work week is 60+, then your pay is 33%+ under what it should be, or is it? Like Aaron says, make sure you figure out how to work a normal week. –  asoundmove Feb 10 '11 at 0:39

4 Answers 4

up vote 5 down vote accepted

Short answer - more than 2 weeks is probably too much. Just as important are short well timed breaks during long, high stress projects. More than 2-3 weeks is too much before you start ramping up for next project.

I was project manager in large projects for 15 + years at a large, technologically advanced company. By large project I mean at least 6 months but more often 12-24 months. A week or two vacation between projects is important. Ask for it, expect it and you will probably get it.

More important is to build "time off" into large project schedules. The rule I learned was "don't burn out your race horses". The only way to avoid that is to build "time off" into schedules. Do it explicitly or implicitly. You can do this in at least two ways. First various tasks in a large project will have "slack time". Rather than compress all the slack time out use it to give people off even a few days. More important watch your people, you are dealing with highly skilled, highly educated individuals. Be sensitive to what is going on, to their needs, family life. As one boss taught me sometimes a day off or half day off to clear your head can be like a week off at another time. Just call or walk up to them and say why don't you take today or tomorrow off. Or if it’s a really big important project, you have the budget, give the person a long weekend and tickets for he and spouse for night on the town or weekend alone in nice hotel to just unwind.Be sure and include cost of baby sitter. Let them choose.

share|improve this answer

Since the clients pay for our project work, there is never a gap between them (or we wouldn't get paid, which is a bad thing!). However, if you feel you need a break, asking for time off about two weeks after the expected end date usually works especially if you ask well in advance. Then the people who assign you to projects will know to plan for the time off in their project plan.

For people planning projects (especially long term projects) do not forget to take leave, sick leave, jury duty, bereavement leave etc. into your project plan. Assume that the person will work no more than 6 hours daily on the project if assigned fulltime and then when leave is taken, the project will not get behind. When people plan that the person will be assigned for 8 hours a day to the porject, then the project plan will faill 1005 of the time if the project is longer than a couple of weeks.

As to the 60-hour nonsense, do not do that. A tired programmer is less efficient and will make more mistakes and create more bugs. Working 40-hour weeks will actually be better for project completion than 60-hour weeks (except possibly one last push week). Anyone expecting a regular overtime as part of their project plan is unrealistic and short-sighted and their projects will suffer. This is a matter of human physicology, tired people work slower and make more mistakes. Planning to have tired developers is dumb.

share|improve this answer

I'd be tempted to frame this more in terms of getting a few things done between the projects:

  1. Was a post-mortem done on the just finished project? Was feedback collected and assessed to see what changes may make sense to do in the next project?

  2. Is the next project ready to get going? Are there changes in the project management methodology as a result of the last project?

Those are what I'd consider to be the signs of how much time is needed between projects. While these may have been done while the triage was being done, there is also a chance that it hasn't been done but should be done before a project launches and expectations are set. From start to finish I'd think most of this could be done in a week, but that requires a few people to put in long hours possibly in terms of getting the feedback, analyzing it and posting recommendations for future projects.

share|improve this answer
    
You definitely need a post-mortem, to find out what went so horribly wrong with the previous project that caused people to work 60 hour weeks for months on end. –  Carson63000 Feb 10 '11 at 1:21

Time BETWEEN projects? That must be nice. Ours always overlap. When development is nearly done on Project A, we're starting on Project B and switching between Project A triage and Project B development.

I would be bored if I had time between projects.

share|improve this answer
    
It is nice! We always have maintenance efforts on other projects that require some attention, plus any R&D. We're never completely idle. –  Mattio Feb 9 '11 at 19:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.