Taking the Crunch Out of Crunch Time
If this month’s guest column strikes a familiar chord with you, welcome to the club. We have all been there. Caught in the maelstrom of unrealistic requirements and damnable deadlines, we grab for whatever tactic looks like it might keep us afloat. More often than not, we start putting in longer hours and expect everyone else to do so as well. As we and the programmers begin to flag, we flog them all the more, exhorting them to tough it out. “Code, code, code!” we call, like the coxswain of a desperately outclassed crew. Work harder, work smarter, work longer. More often than not, it doesn’t work. More often than not, the software is late, buggy and inadequately documented. Johanna Rothman says there are other ways.
Whether you call it crunch mode, ship mode or “death march” project management, mandatory overtime is a standard industry practice. When a software development project begins to slip schedule or is faced with near-impossible delivery demands, the formulaic response is to get people to work longer hours. Soon the project is in constant crisis , keeping people hunched over their keyboards until all hours of the night and over the weekends.
There are many ways to justify mandatory overtime. Sometimes you estimate projects incorrectly and rely on overtime to compensate for bad budgeting or bad planning. Aiming to meet unrealistic delivery dates, you push your people to their limits.
But there are alternatives to mandatory overtime, including choosing to work differently and changing the work to be completed. Understanding what precipitates the downward spiral into constant overtime will help clarify your options.
I’m sooo tired…
Looking at his project schedule, a manager we’ll call Peter sighed and thought, “We’re not going to make it. We’re supposed to freeze the code in two weeks, test for another four weeks and then ship. We can’t be late on this project or we’ll all lose our bonuses. Wait, I know—I’ll get everyone to work overtime! We’ll bring in dinners, and maybe even breakfasts. We’ll do anything, as long as we can ship this product within two months.”
Peter’s staff hunkered down and heroically completed the project, putting in many hours of overtime, including nights and weekends. When they finished the project, senior management requested another project with a just-maybe-possible release date. This time the project team worked three months of overtime to make the release date. At the end of that project, a couple of people quit, but Peter and the rest of the team stayed on.
Over the next year, Peter and his project team staggered from project to project, never quite doing things the way they wanted to, always in crisis mode. By the time they had released two more versions of the product, the entire original project team, including Peter, had quit. Now the company was in trouble. No one on the newly hired staff understood the product, and shortcuts taken by the original project team left the code and internal documentation indecipherable.
Most experienced managers have seen such a project death spiral. Some project managers believe they can achieve impossible deadlines just by getting people to work harder and longer hours. In fact, some management teams never learn how to prevent lurching from project to project. Their unending refrain is “We’re in a crunch. We need to stay focused and keep the pressure on.”
In reality, mandatory overtime rarely helps an organization complete its projects faster. More frequently, mandatory overtime contributes to staff burnout, turnover, and to higher costs in future development.
You may honestly believe that mandated overtime is helping your staff get the work done. More likely, however, you are actually encountering slow progress, as your programmers are creating more defects and much of the work that was done late at night fails to stand up to the critical light of day. If you are considering imposing mandatory overtime, first observe your project, and then consider whether there are better solutions for the problem of insufficient time.
Does progress sometimes seem achingly slow, despite the long hours of work? It may be that your developers are exhausted. Over time, with too much overtime, people can get too tired to think well or to do a good job.
Fatigue builds up in many ways. Some begin to lose their social skills, becoming more irritable and difficult to work with. Some lose their problem-solving skills and start creating more problems in their code than they solve. Some people become disgusted and cynically put in their “face-time” without doing much useful work. When such telltale signs of team exhaustion appear, the overtime people are working can be making your project even later. It may be best to give everyone some time off and to return to normal workweeks.
Another cause of slow progress is that the current staff does not actually understand the product and its objectives. Overtime is unlikely to help in such cases. What will help is to get someone who understands the product to explain it to everyone else. When I suggest this to project managers, their reaction is typically, “Oh no! Taking time for that will put us even further behind.” In truth, if progress is slow and the developers do not really understand the project, the rework rate is probably increasing. Keeping the team from creating still more defects will help you achieve your goal of shipping a quality product on schedule.
As a manager, you should be measuring your rework rate: the time people spend repeating work they thought they had already completed. When the rework rate is high, no one can accurately predict when defects will be fixed. Defects accumulate, as defects in one area cause defects in other areas, and the underlying product becomes progressively more unstable. Bad fixes—the kind that are dashed off in crunch mode without considering the consequences or alternatives—contribute to more instability. Tests become more difficult to conduct on the u.nstable software, slowing progress further and making it less predictable.
You should also watch to see if people are living at work. Have the cubicles degenerated into pigsties? A certain amount of chaos may be the mark of healthy preoccupation, but outright filth is another matter. Workspaces with empty food boxes, soiled gym clothes, and an accumulation of grime are a sign of trouble. When people eat too many of their meals at work and fail to clean up, they are telling you something: they don’t have time to take care of themselves properly.
Maybe your folks clean up their food, but are too tired to clean up their brains. Watch out for whiteboards that say, “DO NOT ERASE UNDER PAIN OF DEATH!” When people are too hurried to document their work properly, they are unlikely be able to remember critical details of what they did. When people start forgetting important things, they tend to create more defects than they can fix. People may be working late only to spend much of the next day redoing the work and correcting their mistakes.
All of these factors—exhaustion, lack of understanding, high rework rate, and people not taking care of themselves—are part of what makes a project seem like marching through molasses.
Even if your team seems to be making good progress, are taking care of themselves, are documenting their work, and are keeping the rework rate under control, you may still think you need to get the work done faster.
As manager, you have some options for completing the work while avoiding overtime. The first step is to tell the project team about your concerns. Don’t expect your programmers to be mind readers. If they don’t understand your concern about release dates, they can do little to help.
Once you have explained you want an earlier release, ask the project team for suggestions. Be open to even off-the-wall ideas; if you are late enough in the project, you may need them.
If you really want to save time on rework and fixes, institute inspections or walkthroughs for all fixes. That one step will save you more time than you can imagine.
Change the Work
Instead of mandating overtime in an attempt to finish on time, consider whether you really need to complete everything on the management wish-list for the current release. Reassess what is truly important for this project. Don’t assume that just because you have been doing something you need to keep doing it. Everything should be up for grabs. You may find people are spending time on things that do not contribute to completion. Eliminate all the extraneous meetings, redundant reports, and make-work activities that can wait until the project is over.
Replan what you need to do, based on what is most important to the project. Not everything is equally important. Rank your product requirements, and see which ones truly need to be part of the coming release. Develop and get agreement on release criteria, so that people know what they are working towards and when they have finished the work.
Managing the managers
Senior management also has options when it comes to overtime, and you can influence managers away from mandatory overtime by finding out what they want and then delivering that. Even when a specific release date is perfectly justified, not everything may be needed by that specific date. Perhaps you can defer some requirements or some documentation or some types of testing.
Where are the degrees of freedom in your project? If the date is truly nonnegotiable, such as a major trade show or a contractual commitment, then explore the feature list and the kinds of defects customers will tolerate. Chances are good that not all features are showstoppers or that customers will tolerate particular imperfections.
If management still insists on all features and a zero-defect product by the nonnegotiable deadline, then you need to get them to see that only a superhuman manager with a staff of superhuman developers could succeed. Management cannot have everything all at once, especially if some demands arise late in the project.
You need to find out the real objective that is driving senior management. After all, if you can’t meet the real objective, there is no point in killing yourself and your team by obeying a mandate for all-out overtime.
One way to find out what management wants is to ask the right questions. One good question is “Who are the real clients and stakeholders?” Clients and stakeholders may be end users, another group of managers, or even middlemen if you sell to people who resell your product or service. For start-ups, sometimes the board of directors is the driving force; sometimes it is the investors who are calling the tune.
Another question is “How will we recognize a successful outcome?” Move the senior managers away from defining a solution to your project management problem—mandatory overtime—to defining their problem and the results they need.
The next question is “What is that solution worth to you?” Maybe you can get more money for contract or outsourcing help. Maybe you can spend money on equipment or training that will make your developers and testers more productive.
The best way option for dealing with overtime is to prevent it. If you join a project at the beginning, talk to the people who set the schedules. Find out their concerns. If, for example, senior managers are believers in Parkinson’s Law, that work expands to fill the allotted time, then develop inch-pebbles instead of milestones. Inch-pebbles not only help you estimate the project well but keep you aware of precisely what is happening and where to take advantage of project advances. Inch-pebbles can help you derive the shortest possible critical path and give you an early alert if you are not meeting your deadlines.
The beginning of the project is the best time to invest in tools and people. If you know of a better way to work, or you know that you need more people on a project, the best time to add a tool or people is in the early days. As Brooks’ Law states, “adding people to a late project makes it later.”
Make sure your team has the needed tools and knows how to use those tools. At a minimum, every team should have a configuration management tool and a defect tracking tool. Consider early when and how your project will use the various peer review techniques to assess and accelerate progress and to reduce defects.
Sometimes, senior management wants assurance that the project team has a proper sense of urgency. I once worked with a manager who routinely took 35 percent off project time estimates. That quickly trained me to pad my estimates by the same amount. I asked him why he routinely cut project estimates, and he said, “I want to make sure people have a sense of urgency. I also want them to have a stretch goal. People need to be challenged!” However, when people are “challenged” with impossible objectives, they often don’t take those challenges seriously and may work no harder than if they were not so “challenged.” Challenges that fall within the zone of the possible may actually help people improve their performance. Outside of that zone, performance declines.
If your senior management wants assurances that the project challenges your team, and that your team has a sense of urgency, ask the team. “Is the work challenging? Do you have a sense of urgency?” If the answers are no, ask, “What would create that challenge and urgency?”
Remember, you don’t need mandatory overtime to deliver quality software on time. There are alternatives. Renegotiating tasks or working differently are ways to succeed without flogging your staff. If you create an environment that allows people to do good work speedily, they will.
Johanna Rothman observes and consults on managing high technology product development, looking for the leverage points that will make her clients more successful. You can reach her at firstname.lastname@example.org or by visiting www.jrothman.com. Besides editing the Forum, Larry Constantine works with companies trying to deliver highly usable products on a timely basis. Reach him by Web at foruse.com.