Getting to Success Instead of Getting to Done

Projects are about getting things done…right?

Uh-Uh.

They’re unique, collaborative, human efforts endeavored to achieve success.  Success is can be defined with certain goals.  Success has a point, a place we reach and can say “Ah-ha!….we did it!”.   There’s a finish line.  Done, on the other hand, is never done.  Excuse the pun.  And the rhyme.

Done is an endless backlog.

Done is a never ending series of requests.

Done is code that’s never perfect.

Done is test cases that still need to be refined.

The fog of “Done” can envelop the project and the minds of our teams.  It obscures the truth.  We’re not looking to get everything “done”.  We’re looking to succeed.  Within success there is room for variation on “done”.

About these ads

Is There a Better Way to Estimate Capital Projects?

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.

What Techniques Do You Use Most To Deliver?

The poll is multiple choice, and you can add your own too.

2012 Predictions

Here’s some of my 2012 predictions, ok…. guesses:

1. Real Options will become a bigger part of planning software and application development projects.  Unlike other projects we’re not discounting a straight stream of cash flows.  We’re discounting a complicated tree of decisions.

2. Scrum Will Breakup – The forces that made it popular will rip it apart.

3. Agile’s Luster Becomes Rustier – The torrent of zealous marketing and hype will take its toll on agile.  There will be increased backlash and doubt through 2012.

4. The Kanban Rock Will be Turned Over –  Executives will look into Kanban for software development and ask “Where’s the value here?”

5.  Managed Service Providers Will Enter Software Development – Utilizing contingent labor available through sites like Guru.com they’re finding ways to drive down the costs of software development for cheap, simple, fixed bid projects.

6.  Agile 2.0 Bandwagon – The agile 2.0 proponents will attempt to reboot life into the “movement”.

7.  Startups get faster, leaner – Driving towards continuous, high quality delivery…some startups will take Eric Ries Lean Startup philosophy further and push tool vendors, or even create their own tools.

8. Tools Start To Takeover – We may have stretched the limits of new practices and patterns.  Time for the tools crowd to take over?  NoSQL and the rejection of OOD&D as too complex for most development efforts may yield simpler higher quality tools.

I never can seem to round out my lists to 10.  How do other writers do that?  Oh well.  See you in the new year.  :)

The “A” Word

Over commercialized, overused and mis-applied the word “agile” has become synonymous with being better, faster, and cheaper.  The hype around the “A” word is nonsense.  Most of the software vendors, consultants, and marketers plastering agile on everything are simply capitalizing on the popularity of some ideas that aren’t even correlated with what their selling.

Agility is not a panacea. It’s not a software tool.  It’s not a product you can buy.  To my opinion it was a state of mind, a way of approaching problem solving.

It’s now lost that meaning.  It’s original luster is awash in a sea of hyperbole and advertising.  When someone says they’re agile or they practice agility….I no longer know what they mean.  It might be that they read a book, they use some self-professed agile software tools, they have a poker planning card set, they bought a CSM certification, or they recently attended some conference on agile software development.   Stop Agilizing Everything was written in protest to the fluff, and monetization of agility.

Will it stop?  I doubt it.

Instead it will kill itself through abuse. Eventually it will become the worn fad of the day.  In disdain and disgust we’ll turn our backs on the “A” word and seek something with more substance.

Santa’s Workshop Goes Agile!

Among the aroma of fruit cake, hot cider, and sub-zero temperatures Santa Claus announced today that his North Pole Workshop would switch to using agile practices in toy production.  Santa sighted a number of reasons for the change, among them:

  • Increasing need to be first to market against growing competition.
  • Better collaboration between kids’ toy lists and toy developers.
  • Reducing the risk that kids don’t get what they want.
  • Increasing quality and accountability in toy development and delivery.

According to Santa, “We’ve analyzed this decision for some time and  it became clear that change was needed after re-reading little Timmy Todsnockerdellturtlefoof’s complaint letter from last year.  Instead of receiving a bicycle, as stipulated in his toy list; he got two fake icicles.”

The well publicized failure last year to meet the requirements of Timmy’s wish list was not the first time Santa’s North Pole Workshop hadn’t delivered, but in this day of social media and instant updates; the story took on a vicious viral characteristic….hitting #1 in the tweetosphere for a full month with the hash tag: #TimmyTodsnockerdellturtlefoofGotIcedBySanta.

When asked what type of agile practice the workshop would be adopting, Santa replied: “Scrum.  It’s well known, proven, and being used in some isolated corners of our workshop today.”  Some muted ‘boos’ could be heard from the audience.

Santa went on to say that Rudolph The Red Nosed Raindeer would head up the agile transformation of the North Pole Workshop in conjunction with an outside agile consulting firm to be named later.  That development confirmed for some that Rudolph was next in line to take over The North Pole.  Rudolph was on hand to comment to reporters after the announcement:

“We’re looking at one of the big 5 consulting firms, but we haven’t ruled out the smaller players.  Look, what’s important here is that we get to done. I have a nose for this kind of thing.  I’m not a dreamer..I’ve been a servant leader for a long time…I realize this transformation isn’t going to happen overnight, there will be pain and there’s a lot of existing process and procedure that will have to….well, frankly….go away.  But, one step at a time. I expect we’ll have a more detailed plan in May or April.  Talk to me then.”

Reactions among the North Pole elves was varied.  One older elf man pointed out that Santa had to be dragged “kicking and screaming to the decision.  He wasn’t on board at all.  Rudolph, Frosty, Mrs Claus and the Yeti really had to sell him on it.  When they broke out Timmy’s letter to remind Santa of the increasing defect rates in his shop….he went ballistic. I mean he really lost his cookies.  Then the Yeti put his foot down.  I think Santa knew what that meant.”

Others, like a younger elf woman, had a different opinion on the switch to agile:  “I’m fine with the whole agile thing, but I guess I don’t understand why they chose Scrum?  I mean….from what I read XP is way better and more applicable to our environment.  I really don’t think the elves, particularly the older ones, will like daily stand-ups. I mean most of them can barely wake up every day….let alone stand up.”

Still another view was held by Donner, “What about Kanban?  No one’s talking about Kanban, but in the reindeer house we use it all the time to limit HIP ( hooves in process). I bet Rudolph moves us there.  I think there’s going to be a power play here between Santa and Rudolph.  It’s a battle that’s been brewing for centuries.”

“Give me a break. Agile?  Really, let’s knock off the buzz and hype.   So we goof up on a few thousand toys out of the billions we make a year.  How’s agile gonna solve that?  I don’t get it.  I guess I’ll ride it out and see where this goes.  But limiting HIP in the reindeer house has done nothing but give some of us more time on our hands.  I don’t think that’s what Santa wants.”  said Blitzen.

Frosty, while at the announcement, declined to make any official comment but did say that he favored a balanced, pragmatic approach, one that would focus on the workshop’s needs rather than a dogmatic approach.

Mrs. Claus had this to say: “Rudolph is very bright.  I know he’ll make this work.  He knows where he’s going.”

Strangely, the Yeti, was not present.  But his footprint could be found in the comments that others made.

Outsiders also came to hear the announcement.  The Easter Bunny had this to say: “I understand what Santa’s doing and to be perfectly frank he’s in a different position from us in Easter Hollow.  He’s facing some real time to market issues and competition with Mom & Dad, Grandpa & Grandma, and others.  His competitors have real advantages in local sourcing, customer relationship management, and technology.  Santa just hasn’t kept up and now it’s time for a radical change.   I don’t think anything he’s doing is going to change our approach.  We pride ourselves on stability of delivery and with a 98.2% market share on Easter…we’re just not facing the same issues.”

The Easter Goose has the other 1.8% of the Easter market.

Merry Christmas agile community.  Enjoy your holidays, stay safe, and as always….take care. ;)