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 you’re 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.

Capital Budgeting Hasn’t Kept up With Agile Practices 

The astute among you will recognize how this financial model of capital budgeting doesn’t fit what you’re actually doing in agile software development.  Big shock…right?  Agile techniques are operational practices.  They aren’t financial, business practices.  Estimating each iteration using planning poker or whatever method has no applicability or affect on the overall investment.  Just because the development team boosted the number of story points in the release…doesn’t mean someone magically added more money.  Capital budgeting doesn’t take place every 2 weeks.  It’s usually an annual event in corporations, although some companies will extend their capital planning for longer horizons ( 2 or 3 years ).  Accounting is the architectural tool that builds business models.  It runs in annual and quarterly cycles.

But It’s Wasteful

Ok, so back to the top.  It may be fundamental to determining the annual capital project garden for XYZ Inc., but the estimates are usually inaccurate and they waste precious time in construction.  Regardless of method…capital projects rarely hit their exact mark.  This pushes many companies to see IT as a money pit to minimize.  Isn’t there a better way for determining our cost basis for capital projects?  Maybe one that doesn’t require us to estimate anything? Everything about capital budgeting is hard to change because it isn’t up to the company.  It’s regulated by FASB.  They define all these rules, and help to police them.  The government recognizes FASB’s standards in lawsuits and for that reason they have the affect of law.   Creative experimentation with accounting standards inside companies is something that people go to jail for. So change in accounting practices and standards is slow and carefully considered.  After all you’re monkeying with the monetary machinery of global industry.  There had better be a good reason for any change. So the next section proposes an idea for change to FASB’s capital budgeting rules.  Do NOT exercise this idea in your company.  There is no provision for this idea in FASB’s standards to my knowledge.  I offer it up simply for conversation and debate….not actual practice.

Relative Targets

When we’re looking at capital projects we need to know the expected revenue ( or savings ) generated by the project after completion and the expenses ( investment ).  Estimating, at least in IT land, deals mostly with the expense side. This is usually done in a very detailed fashion, but with relative targets I’m proposing we skip the estimation and just come up with a tolerance level.  How does it work?

1. Determine your expected revenues ( or savings ) if the project is implemented.

2. Determine your return thresholds.  There should be three.  You could do this with NPV or IRR.

• The return you’d ideally like to get.
• The worst return you’d tolerate ( yes it can be negative ).
• The middle ground between these.

3.  Once you have these 3 thresholds you can then back calculate the capital requirements necessary to fulfill these return levels.  We’ll work through an example in a moment.  But here is the formula we’d use:

Formula to calculate investment for targeted NPV

C = NPV – ∑ R / ( 1 + r )

where

• NPV = Targeted NPV
• C = Investment required to reach targeted NPV
• R = Revenue realized in each period
• r = discount rate

4. Next you’d do a gut check.  Can we really do this project for anyone of the calculated capital thresholds identified?  If we can’t…then we shelve the project.  If we can then we would setup 3 tranches of capital per project correlating to the thresholds.  You’d start off by shooting for the ideal return scenario.  If that didn’t work…you’d make a decision to move on to the middle ground threshold or cancel the project and expense the loss.  The same would occur for the worst case return.

Example

So let’s say we have a project that we know will generate the following savings in years 1, 2 and 3.  Year 0 is our capital investment and what we’re trying to solve for.

Year             Cash Flow
0                 $???,???
1                  $200,000
2                  $300,000
3                  $200,000

Ok, so we know our estimated benefits from doing this project.  Now we need to figure our our three thresholds for year 0 capital funding.   Ideally we want to maximize our benefit.  So let’s say in consultation with the business we determine that these are our NPV thresholds:

• The return you’d ideally like to get:  The most ideal return would be one that requires no investment at all and we receive the present value of the expected benefits – $580,015.02.  But this is unrealistic.  It does, however, give us an upper boundary to our ideal return.  So we’ll say that a more realistic ideal scenario is $400,000.00 in NPV.
• The worst return you’d tolerate:  This could be negative.  Maybe you’re willing to lose money to get this software project completed. Good examples would be where there is a regulatory requirement associated with completing the project.  In this example we’ll say that the worst return we’re willing to tolerate is $100.000.00.  This is above zero, but shows that we’re looking for some monetary benefit.
• The middle ground between these: I’ll just take the average between these two…..$250,000.00.

Great…now we just plug these values back into our formula to derive the initial maximum investment allowed to hit each threshold. We’ll use 10% as our discount rate.

Ideal Investment:

$400,000 – ($200,000/(1.10 )  + $300,000/(1.10²) + $200,000/(1.10³)) = -$180,015.02

This says that the most ideal return would require for our investment to not exceed $180,015.02.

Worst Case

$100,000 – ($200,000/(1.10 )  + $300,000/(1.10²) + $200,000/(1.10³)) = -$480,015.02.

This says that to achieve the worst investment return tolerable the investment must not exceed $480,015.02.

Middle Ground:

$250,000 – ($200,000/(1.10 )  + $300,000/(1.10²) + $200,000/(1.10³)) = -$330,015.02

Here we believe that to get a return of $250,000 we’ll need to make sure our investment does not exceed $330,015.02.

Now that we have our tolerances we can do a gut check and see how realistic it is to complete the project based on each level of funding:  $180,015.02, $330,015.02, and $480,015.02….or anywhere between them.

If our gut check tells us we can complete this project then we’d fund the tranches and start on the project.  If not then we’d drop this project altogether.

Summary

Relative targets take us out of the game of detailed estimating and instead push us to delivery within some tolerances.  This is a more natural way to manage a risky endeavour and affords us some built in cushion that everyone agrees is acceptable to the business’ needs.  We also pre-build fault tolerances, trigger points that force us to reflect on the project’s viability.  Here I suggest that there should be three of these tolerances, but there’s nothing preventing a company from setting up 4,5, or 10.