As most developers can attest, unrealistic timelines for software projects are as common as beer at a baseball game. But why do so many estimates wind up so far out of line? Although causes can range from poor decision making by inexperienced project managers to simple miscommunication, one thing is clear: If you know what leads to unreasonable estimates, you stand a better chance of preempting problems before the schedule is built. Let's look at some typical reasons why projects wind up with unreasonable estimates. Then, we'll consider some steps you can take to help shape more realistic schedules.
Causes for unreasonable estimates
Based on my experience, I believe the major causes of unreasonable estimates include:
- Lack of experience
- Business pressure
- Poor communication
- Organizational dysfunction
Lack of experience
For a moment, put yourself in the shoes of a new project manager. Let’s say that you're asked to attend an early strategic planning session with senior executives. A number of new project ideas are discussed, and before you know it, your project takes center stage. The executives want to know if it is possible for your team to complete the project in six months. You haven’t even had a chance to do any detailed planning and haven’t even talked with the senior developers about their concerns. All eyes are upon you. What do you say? Most inexperienced project managers will say, “Of course we can do it in six months!"—a classic case of a project manager offering or agreeing to an erroneous estimate without knowing what he or she is talking about.
Inexperienced managers may lack knowledge in various areas, including:
- The target environment or technologies.
- The development languages, tools, or platforms.
- The skill level of the available resources.
- The related business (or political) issues.
- The fundamentals of the software development process.
Certainly, more experienced project managers are less likely to promise extraordinary results, but experience doesn't guarantee a reasonable estimate.
Some organizations find themselves in a situation where they are rapidly losing market share to a major competitor. With eroding margins and lost revenue opportunities, they need to release a new product to the market, and they need to do it fast. In these cases, the release date for the product is most likely driven by a date identified by a department other than the IT department, such as the marketing department. This date might be aligned with a national trade show or some type of advertising campaign. In any case, the project manager and developers will probably have little input in determining the planned release date.
I have seen excellent project estimates that included meticulous details for effort, schedule, cost, and scope. Unfortunately, the underlying assumptions or prerequisites that these estimates were based on were not always communicated effectively or understood within the organization. Here are some factors that must be taken into account:
- The dates that key people will be ready to start the project and how long they will be able to stay on the project
- The fact that people may need to be pulled from other duties to work on the project
- The organization's ability to recruit and retain developers with the right skill level
- The necessary education and training that must be made available to the team
- High-level business requirements that are accurate and fairly stable
- The developer tools that must be in place and appropriate to the planned development task
- The development processes that need to be efficiently applied and designed for effective outcomes
- The reliability of any existing software that will be reused
Executives may remember the due dates for major project deliverables, but they may not remember the assumptions. If these project assumptions are not communicated effectively and often, the project estimates may no longer be valid.
The final root cause of unrealistic estimates is something I will call organizational dysfunction. By that I mean an organization that practices behaviors that are self-defeating. One of these behaviors includes a lack of trust throughout the organization. For example, I have known executives who do not trust software developers and their estimates. These executives will always cut the estimates in half because “These software guys always pad the schedule by twice as much!” In these organizations, you will have an epidemic of unrealistic project estimates.
Another dysfunctional characteristic includes managing by fear. If an executive or even a project manager has committed to a project being completed in six months, do you want to be the messenger who gets shot? This environment is similar to the tale of "The Emperor's New Clothes." Everyone on the development team is afraid to tell the truth. As a result, the most absurd estimates will simply be accepted.
If you find yourself in a truly dysfunctional organization, there may not be much hope. In that case, the best solution could be to find a more functional organization or wait for new leadership to replace the dinosaurs who are running your organization. However, if your organization isn’t too far gone, you may be able to take steps to stop an unrealistic schedule from being chiseled in stone. Here are some ideas:
- Do the research. Prepare a list of the high-level tasks you believe will need to be accomplished on the project. Identify rough estimates of effort, schedule, and staffing requirements. Include your underlying assumptions. Shouldn’t this be the project manager’s job? Yes, but maybe he or she is finishing up a higher priority project and just doesn’t have the time. Or perhaps you have a better idea of some of the gotchas that await the project. Whatever the reason, why not show some initiative and do some preliminary planning?
- Collaborate with other developers to get a better handle on the scope of the new project. If there are developers that have worked on similar projects, get their input on the actual effort and calendar time required for their projects. Carefully identify similarities and differences with these benchmarked projects. Having examples, even from other organizations, can be a powerful way to make your case.
- Discuss the detailed information with your project manager before he or she sets early expectations with senior executives. The more concrete information you can provide, the easier it will be for your manager to sell senior management on a realistic timeframe.
If you are regularly faced with bad estimates, there is probably a reason for it. It could be the result of actions (or inaction) by your project manager, or it could extend more deeply throughout the organization. Whatever the reason, the sooner you act, the better your chances of getting a schedule you can live with. But remember: When you approach your project manager, don’t just complain. Give 'em something to work with.