Introduction
“I don’t understand why you keep asking us to estimate the work. With all the time we’ve spent estimating we probably could have completed the first few requirements already. This is a waste of time!!” Ever heard something like this before? It comes across a little naive with regard to capital budgeting. But there’s a good point in the vehemence…. Waste.
In this article we’ll rethink estimation. We’re going to look at the machinery above estimation that catalyzes the need to predict effort and then propose a different way to target capital funding for projects.
Backgrounder
I don’t want to lose anyone here so I’m going to go over some basics of capital budgeting for internal use software projects and how that relates to estimating. If you know SOP98-1 already then skip to the next section. Estimating can seem like a game. At best it’s an educated attempt to predict the future using formulas and experience. At worst its a W.A.G. So why do we do it? It all starts with how we account for the expense of developing internal use software. Internally used software is classified, for accounting purposes, as a fixed, long term asset. In accounting speak: a capital expense. That means it can be purchased for a set price and has a useful life greater than 2 years. Capital expenses, like internally used software, can have their cost depreciated (amortized) over the useful life of the asset. What does that mean? It means that instead of realizing the entire cost of the custom software effort in one year…..you realize it over the useful life of the asset. So if we intended some custom built workflow system to last 5 years and the entire cost of the initial development effort was $312,333.04 then we’d (in a simplistic amortization schedule) realize, report $62,466.61 in expenses per year for 5 years on each annual income statement. Further the software’s depreciated cost would be listed as an asset on the corporate balance sheet each year until the full value had be amortized. The ying to the capital expenditure yang is the operating expenditure. Operating expenditures are incurred, realized as they are spent. There is no depreciation of cost. If I have $125,000.00 in operating expenditures this year then $125,000 in expenses shows up in the income statement. Operating expenditures are not considered assets and companies routinely seek to minimize their cost and flatten their growth. How do they do this? Well….one way is by investing in capital assets that can help increase productivity. So if I invest in some custom workflow system that will reduce the number of FTEs (full time employees) I need by 10% then that’s a potential long term realized gain in operating expense reduction: a.k.a. more profit for shareholders. Capital expense accounting can seem like magic if you’ve never heard of it before. But there’s a very real justification behind it. What is that? Simply put: if your capital asset increases profits each year after it’s implemented then those profits should be offset each year by the cost to develop that asset. Fundamentally, capitalization of IT expenses is an immense part of why companies invest so much in new technology. The accounting allows us to derive value from capital investments. Yes, technology is wonderful, but if internally used software expenses weren’t capitalized you’d see IT budgets shrink drastically.
Estimating
Awesome. So how does this relate to estimating the effort on a software project. Remember this line from above: That means it can be purchased for a set price and has a useful life greater than 2 years? A capital project is an investment or a series of investments. Knowing the price up front each year creates two things:
- The funds needed to purchase that investment.
- The cost basis to use in constructing a model of investment return.
Each of these capital investments are compared against each other using a % return ( IRR ) or more commonly using NPV (Net Present Value). Some are required and ‘must be done’. But the rest are optional. So leadership uses the projected investment return to determine which ones will benefit the company most. That becomes a short list of capital projects to fund for the fiscal year. Now, when these projects are initially compared developers may have been involved in the estimation process or they may not have been. But regardless the estimate is usually classified as a ROM (Rough Order of Magnitude). Once the project is funded another round of more detailed estimating occurs with the development team for the strict purpose of validating the ROM. If our detailed estimation shows we have inadequate funds then we need to make a decision: cancel the project or increase the investment. But if we increase the investment…how does that affect our return? Should we do a different project instead? You see where it’s going. Estimation is a fundamental part of determining the capital project landscape. It’s the basis for determining the initial and subsequent investment to achieve an estimated return. Software is just a means to the real end: increasing organizational productivity.
Comments