based on reliable anecdotal experience. We will evaluate the project's Return on Investment (ROI) and show that unless the hidden cost of free time is considered, organizations will usually invest in the wrong project.
Hidden Effort and the Same Return - Example 1
On Project One, the project manager disregards any accounting of free time even though in the past his projects have burned out the team members with a steady diet of sixty plus hour weeks. He estimates 100 units of labor are needed, and overlooks the previous fifty percent error in estimating, since he assumes his team will "suck it up" and work any needed overtime to get the job done. After all, if he included that effort, the project might not be funded.
On Project Two, the project manager takes into account historical data which shows previous similar projects really took fifty percent more effort than initial estimates, so she estimates 150 units of labor.
Project One has an estimated return of 150, and Project Two a return of 200 (this example assumes labor cost is the predominant project cost, which is true in software development-a key point discussed later). However, with the lower estimate for Project One, Project One's ROI is 150 versus 133 for Project Two. The company decides to invest in Project One.
However, if we follow this example and assume that both projects take 150 units of labor to finish, the ROIs are reversed. As the green bar in Figure 1 shows, Project One returns 150 units for an ROI of one. If Project Two had been chosen, and came in on a budget of 150 units, the ROI would have been 133 as planned. The company just lost thirty three units of return. In this case the higher cost estimate returned more.
Figure 1 - Example 1
This example makes a number of simplifying assumptions, but I believe it usefully demonstrates how ignoring the estimation of free time will lead to making bad decisions. Whether or not the overtime is compensated, it is a resource that represents the most valuable commodity in a software development organization-the intellectual capital of the development teams. When it is spent, it should return the maximum. In the example, both projects used the same number of units and one had a thirty three percent greater return. You can adjust the numbers to show any number of cases where ignoring the effort will result in the wrong decision.
Lower Return Project Selected - Example 2
Take two projects where the paid effort is the same, and both assume a fifty percent free time budget, but the first project ignores the free time "because it is free." It automatically gains a large advantage in the decision to select one of the two competing projects (see the "Estimated ROI" bar in Figure 2). In the case where both projects return the same value, there isn't a problem. However when the accurately estimated Project Two has a higher value, the correct decision is hidden by the inaccurate effort estimate of Project One. As shown in Figure 2, the actual return is the opposite of the estimated return.
Figure 2 - Example 2
Why Isn't The Hidden Cost Counted?
Software projects are typically dominated by the cost of effort. Systems and hardware projects are more equally weighted to equipment, material, and manufacturing costs, so the ROI calculations do not show the same story. I suspect many of the mental models used to make project tradeoff decisions have not made the transition from physical costs to intellectual (person hours) cost.