Time out work is not feasible

Recently, I saw an interesting question on a software development team that they need to work more hours to meet a launch date.

The original question reads as follows:

My team has a launch date two months out that we need to hit. Over the past year I've been comfortable with them working 40 hours per week, but momentum is drawing with vacations, early weekends, etc. I need to communicate that they need to step up their effort and work more hours per week until we launch.

My team has a project to go live in two months. In the past year, my team and I worked 40 hours a week, but the progress of the project declined due to holidays and other factors. I need to communicate with the team asking them to work longer hours a week until the project is formally launched.

My question is specifically about the best way to communicate this request.

Specifically, my question is, how do I communicate such a need to my team?

From the point of view, the questioner should play a PM-like role in the team, and the content of the question is also very common in practice, which has aroused many people's replies. Among the many of the answers, the highest-rated, and most intriguing, answer was given by former Quora engineer Edmond Lau.

In his reply, Edmond Lau explained why he considered working overtime unfeasible and shared the painful experiences that he personally encountered in the execution of his past projects. The entire answer text is much longer than the original question text, but it is very practical and interesting. I felt very much like it after I read it, so I wanted to translate it well and hopefully brought some thoughts to my friends who encountered similar problems.

It should be noted that I am not a professional translator. Therefore, we are very much welcome to correct the translation of the text, which may or may not be in place (which is very likely to happen). If you have the relevant experience can be shared, then it is even better, this is also the beginning of my translation of this answer, I hope to bring everyone's help.

Translation

Before asking your development team to work overtime, make sure that your current online plan is really workable. If on schedule, it seems like wishful thinking, then your best strategy is to re-order the finished product content that you can deliver on the date of launch, based on the current project status, or, depending on the project The current progress status, re-set more feasible on the date.

It is very difficult to deal with the developing process of sliding down, but unfortunately it is very common. I've been involved with two large projects that have development timelines spanning months, in which the ambitious project manager always asks the team to work overtime in order to sprint over the delivery of the project.

In both cases, as we were told, once the project failed to be completed on schedule, it would cause serious business losses. So many of our team's talented and willing members are trying their best to try to achieve such "optimistic" delivery. We work 60 hours a week from the beginning until we grow to nearly 70 hours a week.

After months of overtime, the project still can not end. The final result proved that in such a project marathon, we only ran in half, not close to the finish line. Undue overtime sprint makes no sense. (It turned out that rather than sprinting at the homestretch of a marathon, we had started sprinting somewhere near the middle.)

In these projects, the enthusiasm of the team members was burned down and some of them left one after another. And this allows the rest of the team to take the extra time to take over the job of the departing member. In the short term, it seems reasonable to make overtime decisions to pursue more progress, but in the long run it hurts the development team.

The experience of these two projects taught us a painful lesson: when you want a project to be completed within a specified date, it does not mean that the project can really be completed by that date. Do not confuse two things, wishful thinking and optimism. just because you really want a project to be completed by a certain date does not make it any more more that that will will. Do not confuse wishful thinking with realistic optimism.)

Why overtime work is not feasible?

Your thinking may look something like this: The current schedule is 25% behind schedule, so in order to catch up with the original project delivery, you need to spend 25% more hours on the team to keep up. This means that each team member needs to work 50 hours a week over the next two months. (Annotation: The original questioner explained that they are currently working 40 hours a week)

Here I offer some reasons why such thinking logic is not practical in practice, and why it is not always possible to work overtime to catch up on date:

1. The hourly productivity will decrease with the increase of working hours

If your team is accustomed to a 40-hour working pace for a week, the extra productivity of marginal productivity may well be lower than normal working hours and may even be negative. Fatigue and decreased sleep will eventually hurt cognitive function and reduce the quality of work.

Nearly 150 years of research on how long hours work to reduce productivity can be summarized in two research papers by Sara Robinson's Bring back the 40-hour work week and Evan Robinson's "Why crunch mode does not work." In the 1890s, each laborer was more productive at an hourly rate of 8 hours per day [1]. Sidney Chapman demonstrated in 1909 that overtime work would lead to a rapid drop in productivity and labor began to commit the mistakes that they would make without adequate rest. The cost of follow-up, their output will decline in the next few days [2]. Henry Ford started working in 40 hours a week in 1922 as years of experimentation told him that such a system design could boost the total output of labor. [3] [4]

Tom Walker wrote the following description in The Prosperity Covenant:

"The output of work does not change proportionately with the rise or fall of working hours, and this seems to be a lesson learned for every generation to relearn." [1]

The decrease in marginal productivity means that if overtime can increase the team's total output per week, the total output will not increase by as much as you expect by 25%. (Even though the output of backward projects still lags behind even if the total output is increased) ). But a study of the 1980s, "Scheduled Overtime Effect on Construction Projects," even questioned the argument that overtime would raise total weekly output:

"Weekly working hours last longer than 60 hours and lasting about two months. The cumulative effect of a decline in productivity will lead to a delay in completion dates, which may even be the same as the completion dates of 40 hours of normal working hours per week. [5]

This research may not be the subject of software development industry, but this does not become, we do not learn the reasons for more than 100 years of research.

2. There is a great chance that the team is currently behind schedule more than you know

Accurate project estimation is one of the most difficult projects in engineering [6]. The current project's decline in schedule represents a lower-than-expected output from your previous months, and is optimistic that only the previous output Estimating less than expected, it is more likely that the estimate for the entire project output is wrong. This also includes your expectations of the next two months' output.

The more often the effect of making the uncertainty of the timing imprecise is that we tend to estimate the project timing accurately at the beginning of the project, and at this moment we predict the timing based on which we already know how to proceed The development work, rather than the overall project of the project. Teams often underestimate the time it takes to consolidate tests, and these underrated work items often drag down the overall workweek for weeks or more.

Frederick Brooks writes this effect in The Mythical Man-Month:

"There is not enough time for systematic testing, which can have disastrous consequences in certain circumstances because delays in testing result in a fall in the project's time history, and only when it is close to the project's delivery date Aware of this "[7]

3. Additional overtime hours may burn your team members

Overtime hours for team members come from sacrificing their extra time - perhaps the time they spent with their friends or spouses, the time of exercise, the time of rest, the time to sleep, or something other than work. When we want them to sacrifice these times and switch to high-pressure man-hours, the enthusiasm of the burning team will be hard to quantify.

In Peopleware (Peopleware), Tom DeMarco and Timothy Lister call one of these phenomena "undertime," while workers work overtime to work "total It will help us to steal the same length of crooks so that our own life can be compensated. "[8]

In our experience, the positive energy of overtime has always been exaggerated, and its negative effects have never been considered. And these negative effects can be said to be very practical: easy to make mistakes, exhausting enthusiasm, expediting the departure of employees, and compensating "undertime." [9]

4. Overtime may hurt the team's enthusiasm

Not all team members have the resources to cope with extra man-hours, there may be children in member homes to take care of, members may spend a very long time in commuting, compressing the time available for additional work, or having members planned The next two weeks of the holiday.

At the beginning, the team was in a positive state, and everyone was in the same place for 40 hours a week. But now everyone is asked to devote more hours they can not or do not want to invest, and the result can be pain or resentment among otherwise happy team members.

Hurried rush to work leads to additional management costs

Overtime work will require additional stand-up meetings to ensure that each member is doing the right thing, and unfortunately those extra conferencing and communication costs are not included in the original working hour estimate.

6. Rush time may result in additional technical debt

The hard part to avoid is that when you ask team members to work overtime to reach delivery, they often take the shortcut to achieving their goals in development.

Perhaps they will write down their notes responsibly and tell themselves that they have to go back and deal with the problem after the project ends, but they usually start to invest in Project B after the end of Project A and can not go back to their expectations as expected. So after the end of the rush project, the team usually leaves behind a whole lot of technical debt waiting to be repaid in the future.

These costs are not theoretical, but actually happen in the projects I'm involved in. And unfortunately, these situations are very common in software projects.

But these things will not happen to me

Leaving aside these long-term costs mentioned above, I also understand the difficulty of saying "no" when changing lanes and going up-date. Maybe other people in the organization are looking forward to getting the project online for quite some time; perhaps the project is so important that if the project is late it will cause a commercial loss; maybe you are afraid that your team will not know if the project is delayed What happened? Or, maybe you think you and your team's situation will be different.

Whatever the reasons behind, if you are still insistent on wanting to ask the team to work overtime, I suggest you and your team focus more on the following items:

1. Discuss with the team and clarify the main factors that have caused the current project to slip

Is the decline in project timing due to member slackness or because development is more complicated and time-consuming than expected? If you do not understand the underlying causes of project lag, then you can not convince you of these factors, not in the next two months Will happen again.

2. Explain to the team the truly feasible New Time Plan and explain to them why the overtime can really make the project go online smoothly

Just telling team members that it is not enough to work overtime because they are outdated will be a warning if you are not discussing a more detailed and workable plan. Because it is very likely that the work required next will be much more than what you now think and overtime is not a good solution.

3. Make sure project members buy-in for the new schedule

If the project's key person does not agree with the new schedule, it is possible to think whether you "could have done something in one day" or "something that was" really "OK Then you need to consider that you might be conflating what you want to get done by a certain date with what is realistic to get done by that date.)

If you do not allow everyone to pay for it, only some of the project members will actually work overtime to catch up, even if that will hurt the team's fairness, and you should not want the project to go live on the dates you expect.

4. Explain the general direction of the team and explain why it is important for the organization to go live on time

If you can not bring together all the team members, then this will be another warning. Because all team members, will not be standing on the same starting point with you, overtime work.

in conclusion

Finally, if during the two months of overtime, you find that your progress is lagging behind in the new project schedule, then you should be prepared to give up this overtime. Accept that you are still in the middle of a marathon and that the finish line is farther away than you thought. In this case, ask the team to work harder to solve the problem. What you should do is get rid of your losses and try to figure out the next contingency plan you can make.

Failure to go live on schedule can be bad, but worse is the burning enthusiasm of the team, which still does not go live on schedule and is still not effective for the new dates. It's not easy to handle the slipped up date.

[1]: Tom Walker, The Prosperity Covenant: how reducing work time really works to create jobs.

[2]: Sydney Chapman (economist), Wikipedia.

[3]: Samuel Crowther, Henry Ford: Why I Favor Five Days 'Work With Six Days' Pay, World's WOrk, October 1926.

[4]: Ford factory workers get 40-hour week - History.com This Day in History - 5/1/1926, History.

[5]: Scheduled Overtime Effect on Construction Projects, Business Roundtable, 1980.

[6]: What are some ways to improve your project estimation skills?

[7]: Frederick Brooks, The Mythical Man-Month: Essays on Software Engineering, p20.

[8]: Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams, p15.

[9]: Peopleware, p179.