Larry Putnam, Jr. recently presented a short tutorial on the benefits of Top-Down Estimation for Software Projects:
- Top-Down Estimation methods provide the data needed to make early decisions because most software project schedule and cost decisions are made early in the project or product lifecycle
- Savings Associated with Top-Down Estimation
- Top-Down Estimation vs. Detailed Planning
- Sum of the Parts Don’t Equal the Total Time & Effort Required
- SLIM Software Equation Supports Effective Negotiation
Watch the video or continue reading to learn why the QSM SLIM methodology gets you the data and analytics to make software project commitments with confidence.
Benefit: Provides Data Needed for Early Software Project Cost and Schedule Decisions
Top-down estimation is the estimation methodology implemented in the Quantitative Software Management (QSM) SLIM-Suite® of tools. One of the benefits of top-down estimation is that it's compatible with the information available when we have to make important cost and schedule decisions. If you think about when most costs and scheduled decisions are made on software projects, it's usually very early in the product life cycle. Size and scope metrics available at this stage are fairly high-level. We can usually find things like epics in an agile-strong environment or high-level requirements, and if nothing else is available, we can do T-shirt sizing based on the analogies of how this project compares with other projects we've developed in the organization.
Another key benefit is that Top-Down Estimation embraces uncertainty inherent with software project estimation and allows us to quantify the probability and risk associated with stakeholder targets for cost and schedule. Moreover, it quickly allows us to generate alternatives that may satisfy stakeholder objectives.
Benefit: Top-Down Estimation Cost Savings
There's also an economic value of top-down estimation because it relies on top-down, high-level information on scope, expected staffing levels and productivity. It can cut estimation time to hours or days. This time and cost savings is amplified if we have a modest amount of historic data. Alternatives are easy to generate and bound most stakeholder objectives.
Bottoms-up planning requires much more detailed information on Work Breakdown Structures, tasks and resource types that are simply not available at this stage of decision-making. Estimation times can take many weeks to months to try and derive this level of information and can involve many subject matter experts whose time is better spent defining the customer solution than trying to create detailed plans when the scope is ill defined. Any changes to the bottoms-up estimate assumptions require additional, lengthy and costly rework cycles.
Benefit: Top-Down Estimation vs. Detailed Planning
I find that it's important to differentiate top-down estimation from detailed planning. So, estimation is really about taking what is known about the scope of the customer needs and transforming that into a reasonable big picture timeline and staffing and cost baselines that meet customer expectations. Planning, on the other hand, is the process of defining the customer needs at a much lower level to support task execution, resource allocation, and to get the job done within the estimated schedule and cost bounds. They are both very complementary. When used together, they increase the probability of successfully delivering customer needs within the negotiated schedule and cost commitments.
Let’s look at some of the things that QSM has discovered over the last 45 years in terms of how software projects behave in terms of their demand for resources as the amount of scope changes. Below is a graph with schedule, effort, and defects on the vertical axis and size and scope on the horizontal axis. If I took a recent sample of data out of the QSM historical industry database and do some regression fits through schedule versus size, effort versus size, and defects versus size, and plot those profiles on a set of linear axes, these would be the curves that you would see. So, if we look at the schedule or the time curve, we see that when we're down in the fairly small size regime — small projects. Notice that small changes or any changes in scope tend to have a fairly big impact on the schedule. The behavior is almost the opposite in the effort and defect region. Once we get into the larger systems, small changes or any changes in scope tend to have a bigger impact on the effort cost of the system and how many defects we create. This is the fundamental behavior of every software project.
During bottoms-up planning, we're usually working at the very detailed level — individual tasks and how long they should take, how many people we're going to need over that timeline. And we're almost always working down in the small size regime. This means our schedule estimates are always going to be down on the lower side of things. And if we do that for all the tasks that are associated with the system and simply add those up, we tend to shortchange ourselves and won’t have enough schedule, because when you put it all the scope together, instead of being down here on the left side of this curve, we're actually way up to the right. It's a much bigger system when we put everything together.
Top-down estimation focuses on the size component, the total size of the system, right off the bat and that way we can see where we on these curves. Then we can pick the appropriate amount of schedule and the appropriate staffing and cost numbers. We also get a handle on how many defects we're likely to find. This behavior is all backed up by research that QSM has been doing for the last 45 year using industry data that we've been collecting along that timeline.
Benefit: SLIM Software Equation
What makes QSM's top-down scope-based estimation work is a very simple equation. We call it the Software Production Equation. Conceptually it is pretty simple. Software projects are undertaken to create value for our customer that we quantify in terms of the size and scope. Early on, we're looking at big high-level measures. It might be the total number of epics that we've got to deliver, or high-level requirements, or we may do analogy-based sizing. But it's basically a quantification of what we have to deliver to satisfy the customer need. This delivered size is going to be equal to how much time it's going to take and how we're going to apply resources over that schedule. This is the time and the effort component. Lastly, we are going to have to operate at some level of productivity. The level of productivity is going to encompass multiple things, like how efficient we are, how well we know the application, what tools and methods we are using, the complexity of this particular system and how it interfaces with external systems. All of these factors that affect our productivity is built into this productivity term we call a Productivity Index within the QSM methodology.
The nice thing about this is we can rearrange this equation fairly quickly, so if I needed to figure out what is my productivity with my team and in my environment, we just rearrange this equation where we look at past projects and we see what did we deliver, in terms of the functionality for this project? How long did it take? How did we staff it over that timeline and what was the effort that we expended on the project. And then we can determine this productivity empirically for our group or organization or different organizations within the company. So, it's easy to sort of look at and manipulate this equation to depending on what we're trying to do.
You'll also notice that we've got these little exponents next to the time and the effort. And what that's getting at is this notion of incompressibility of time. When you try to accelerate the schedule by using a large team of people, you get diminishing returns on the amount of schedule compression you can achieve. Likewise, if you move in the other direction, if you can afford to take a little bit more time and a smaller team, you can significantly reduce the effort and the cost of the system. And again, these are empirically derived with over 45 years’ worth of data.
Benefit: SLIM Software Equation Supports Negotiation
On the chart below, what we've done is rearranged that software equation into its estimation form. If you look on the right-hand side, you'll see the inputs on the left side of the equation are functionality or size and scope, and productivity or efficiency. That's what we feed in. Then the Software Equation will estimate the amount of effort and time. And it just doesn't estimate one effort in time that allows us to explore a number of alternatives and make changes. And on the left-hand side I've laid out some of the situations you're almost certainly going to encounter when it comes to estimation.
- The first one is we've got a fixed budget, so I've got a certain amount of money the customer is allocating. We're not going to get any more. If I look at this equation, notice that I've drawn a little box around the effort term, so that's the indication that's locked down. And then we're looking at the other terms and you'll notice I've got a little padlock that's next to this efficiency or Productivity Index term. And what that's saying is that parameter is fixed in the short term. We're not going to be able to do anything, you know, tomorrow to drastically increase our productivity. That happens through targeted long term, process improvements and investments in order to make our efficiency go up overtime. You'll notice the other two terms, functionality and time, have little arrows next to them. And that's saying is those are the parameters that we can adjust to try and make sure that we can fit within that fixed budget or fixed amount of effort that's available to us. I've got a little up arrow next to the time, which is saying we could take more time and exploit that trade off relationship and use a smaller team to bring the cost down, or I could reduce the functionality in a similar way. Less scope will obviously bring our effort and our time down. Or it might be a combination of both of those things - take a little bit more time maybe, you know, prioritize the functionality and put low priority stuff in a in a second release. But those are the levers that are available to us to figure out a solution in that fixed budget scenario.
- The next one is a fixed duration. So, we just move that box over to the time term. And again, we can see a couple things that we can do is exploit that trade off where maybe we use a bigger team to try and get some schedule compression to meet that time commitment or we can also reduce the functionality to reduce our cost.
- If we're looking at a fixed budget and duration, so both of those things are fixed, then the only thing available to us is we've got to figure out what's the right amount of scope that fits within that time and effort box. Having said that, you still have a lot of alternatives to look at to try and optimize on what is most important to your stakeholder. Maybe I use their smaller team to optimize on cost, or maybe I use a little more team, you know, or a larger team to try and optimize on schedule. So, there's a fairly good amount of horse trade that we can do even within the boundaries that we have on the schedule and the effort.
- And then if scope is what's fixed, so we've defined what our minimum viable product is and the customer won't accept anything less than that, then the only thing we can really do again is negotiate a reasonable amount of time in a reasonable staffing and effort to get that job done.
So, the nice thing here is this simple little equation lets us explore a number of different alternatives based on the situations that we're likely to find ourselves in in the future.
If you’d like to learn more about what top-down software estimation and control tools can do for your organization, check out our SLIM overview or contact us for a customized demo.