Why Agile? Project valuation

(Part 1 of an unknown number of articles exploring why I think agile methodologies offer benefits to all project stakeholders and sponsors)

I find myself pitching agile more often than I expect. Agile development isn’t a panacea, but it’s a decent approach to the world of challenges that face software development teams and their customers. In this brief post, I’ll cover one of the things I love about agile: the financial benefits of incremental development.

One of the things that development teams often forget is the time value of money. Basically, all that means is that money in your pocket today is worth more than money in your pocket tomorrow. Let’s walk through an example of how iterative development increases project valuation.

Alice and Bob

Meet Alice and Bob. Alice is developer for Acme, and she makes a lot of money. For math’s sake, we’ll say that she costs the company a total of $100k / year. Let’s also meet Bob, the customer service rep. While Bob doesn’t make nearly as much money as Alice, he sure has a lot of peers in the call center. Let’s say that Bob costs the company $50k per year with benefits, etc.

It’s been a great year for Acme. They’ve seeing growth in their business, and they’re expecting to additional four customer service reps over the next year. Of course, they’d rather not have to, because that eats into total profit. Alice’s team, though, has been working with Bob’s boss, and developed a list of ideas that can improve productivity to the point that they don’t need to hire additional people to handle the increase in customer volume. They get together, put those ideas into a project cost-benefit analysis, and start crunching numbers. Here’s where they land initially:

Project Charter v1

So, what does this look like from a cash flow perspective? Let’s draw it out (click the image for the a slightly larger version):

As you can see, Acme’s paying Alice for the work she’s doing, but not seeing any benefits from it. If we were to calculate the net present value of the project over a three year basis (at a 12% cost of capital for the financially minded), we’d see that the project is worth about $201k. This is of course, good, but let’s see what else we can do with it.

Let’s assume that Alice works with her partners to break the project down into smaller chunks. The charter would then look something like this:

Project Charter v2

What’s different? The costs and benefits are the same, but we see that the waterfall milestones have been replaced with things that have meaning (and benefits) to the business. What does this do to our cash flow projections? (again, click the image for the a slightly larger version)

So, the business is seeing financial benefits earlier. What does this do to project valuation? The three year NPV of the project is now $251k, about a 25% bump from the first model, just by altering the project approach. Of course, these changes will also affect the way QA does their work, the CSR training team, etc, etc. What does it do to hiring needs? Depending on the timing of the project deliveries, Alice (and her team) may be able to stay ahead of the business’s capacity needs. Perhaps Acme now has the opportunity to increase hours of it’s part time CSRs without having to place new permanent hires. (If you’d like to play around with the cash flow model, you can download an Excel version here)

Clearly, I’ve stacked the cards here with an easily divided project that’s a clear winner. And dividing projects up like this in real life is hard — really, really hard. That said, in most software development it is possible, provided that the move to production does not require significant costs (e.g., replacing chips in devices you’ve shipped). What do you think?