Section 3.4.  Diagnosing Estimation Problems

3.4. Diagnosing Estimation Problems Estimation problems almost always boil down to estimates that are either too high or too low. Padded estimates, where the team intentionally overestimates in order to give themselves extra time, are a chronic source of estimates that are too high. Senior managers giving unrealistic, overly aggressive deadlines are a chronic source of estimates that are too low. In both cases, this can lead to morale problems. There is a basic tug-of-war going on here. Engineers prefer higher estimates, giving them as much time and as little pressure as possible to do their work. Managers prefer to deliver things more quickly, in order to please stakeholders. The only way for a project manager to avoid this conflict is to work with the team to produce estimates that are as accurate as possible. By adopting a sound estimation process that allows the team and the project manager to reach a consensus on the effort involved in the work, the morale is maintained and the work is much more predictable. 3.4.1. Padded Estimates Generate Distrust In some organizations, the project team drives the entire estimation process and the project manager simply builds a schedule around their estimates. This can be comfortable for the team, but it does not always work well for the organization, and it can eventually lead to an environment where the managers don't trust the programmers. There are many reasons why estimates are wrong that have nothing to do with the work being done. Software engineers are often overoptimistic by natureit's easy to be very positive about a project before doing any of the work, and it's easy to ignore problems that may come up later. It's very tempting to pad estimates, since they lead to longer schedules and less pressure. The situation is especially bad when someone with no formal training in software engineering and little experience estimating software tasks is asked by her manager to give estimates. She is forced into a difficult situation: if her estimates come up short, she will be penalized at her next review. She could pad the estimates, but that would be dishonest. Her manager will eventually catch on and start cutting down any estimate she provides. Either of these options can lead to unreliable estimates that throw off the entire project planning process. She feels like she's left hanging with little support, and if her manager sees that her estimates are off, he could end up distrusting ones she makes in the future. A programmer who knows that there will be ramificationsa poor review, a lower raiseif he does not meet his estimates may pad them, often extending his estimates by a factor of two or three. Managers will usually catch onto this, making it clear that they don't trust the programmer's estimates and asking for the tasks to be done early. The programmer, in turn, will only pad the estimates more. This "arms race" usually leads to a complete breakdown of the planning process. A project manager could avoid the problem of estimates that are chronically padded by having the team reach a consensus on their estimates in an open meeting, where team members are less likely to pad their numbers. Team members who have thoroughly discussed their assumptions about the estimates are much less likely to be overly optimisticthey remain more grounded in the facts of the project, and will not sweep as many details aside. It may be tempting to pad estimates when delivering them by email; it is much harder to pad them when sitting at a table with everyone else on the team, knowing that one's estimates might be challenged and would have to be justified on the spot. 3.4.2. Self-Fulfilling Prophecy Some project managers respond to an unrealistic deadline by creating "estimates" that are too low but that meet it. Sometimes a team makes up for their project manager's poor estimates through enormous effort and overtime. When this happens, those poor estimates become a self-fulfilling prophecy instead of being an honest assessment of the work that the team expects to do, the estimate turns into a series of baseless deadlines that the team must meet. The team never agreed to these deadlines, nor did they have any input into them; when this happens, the team will begin to resent their project manager. This is especially common when the top programmer is promoted to project manager, and fails to take into account the fact that he works faster than the rest of the team. (When this happens, the project manager's bond with other programmers will make it more likely for them to agree to the deadline and work much harder.) But any project manager is susceptible to this problem. Typically, the self-fulfilling prophecy happens when the project manager is the sole source of estimates. He will create a project schedule with aggressive deadlines. Often, he will set the deadline first, and then work backward to fill in the tasks. The effort required to perform each task is not taken into account, nor is the relative expertise of each team member. If the deadlines are too aggressive but not entirely impossible, the team will work to meet them. This may seem like a good thing to the project managerhe was able to get more work out of the team. But, as the team begins to burn out, they start to realize that they are working toward an unrealistic project schedule. The project does not go smoothly. Instead, it alternates between normal working time and crunch periods, and there is little advance warning before the crunch periods begin. The first few times that the team meets an unrealistic schedule by working nights and weekends, they are happy to have met the deadline. But each time this happens, the project manager's undeservedly high opinion of his own estimating skills is reinforced. Eventually, the team gets disillusioned and bitter, and the sense of camaraderie that was forged over the many late nights and high-pressure assignments is overwhelmed by anger and frustration. Had the project manager used a consensus-driven estimation process, the team would have been able to go into the project with a real understanding of what would be asked of them. They would know at the outset that the project would require crunch periods, and would be able to plan their lives around them instead of being blindsided by them. And the project manager would be able to keep the team together, without causing them to feel bitter or exploited.