Practical Software Measurement

Bottom-Up? Not So Fast...

One of the most common objections we hear from companies with regard to getting started with top-down estimation is that it’s not needed, because they already have a detailed planning spreadsheet in place. Customers will concede that their estimation practices are not perfect, but that they are working “OK.” But, when it comes to spending your company’s money on software projects is “OK” enough?  

Let’s take a closer look at what these companies mean when they say their estimation practices are OK.  What we often find is that many are practicing bottom-up estimation, rather than the top-down process that QSM has found to be most effective.  Bottom-up estimation requires each project team member to estimate how many hours it will take them to complete a particular task, then the manager of that project collects all of the individual task estimates and rolls them up in a spreadsheet to get the overall total of hours for that project. The bottom-up technique provides the illusion of early control and perceived accuracy due to the availability of information such as headcount and hourly cost rates.  However, usually before a project starts there is not enough information available to really know how many hours each task will take and how the overall project environment will impact each task.  In reality, the team member is giving their opinion based on experience regarding the amount of work that they can do in a specified amount of time on a task that might not be fully defined before the project starts.  Unrealistic project goals, miscommunication among team members, and typical project non-linearity leads to rework cycles that are rarely accounted for in bottom-up estimates. In addition, usually the complexity of the work is not factored in. Complexity impacts efficiency and efficiency impacts the duration, budget and reliability.

In contrast, a top-down approach looks first at the scope of the project and factors in the efficiency of the team and the complexity of the work. It allows us to put a stake in the ground early to find the right duration and the right budget before spending hours making a detailed plan. We need to know if the project is going to take 6 months or a year, with 10 people or 30, before we ask 40 people to provide feedback on their task plan. Top-down can save days in the planning process and millions of dollars in schedule adjustments.

By moving to a top-down estimation approach, companies can fully realize the efficiency and flexibility gained from having good development standards and processes. 

The Role of Two Different Sizing Approaches


Increased accuracy as a project progresses and additional data becomes availableDifficult to do early in a project without detailed information available
Offers a very granular way to decompose a project
Requires significant effort and data granularity
Provides connection to detailed project planning
Hard to account for non-linear relationships
 Highly variable and subjective assumptions around personnel and team productivity



Ease of use early on, especially with minimal project information - when pivotal commitment decisions tend to be required
Dependence upon reliable data sources
Flexibility and the capacity to deal with the unexpected
Dealing with a perceived loss of planning control by developers
Promotes the use of historical data and productivity measurement
Typically less expensive than other estimating methods
Facilitates much easier and rapid "what-if" project planning scenarios and alternative analysis
Blog Post Categories