Software by numbers: Chapter 2

[Valentin Crettaz]

I'm reading through Chapter 2 - The new ROI of the book available on Amazon. Given that we can make numbers say pretty much anything, I'm really curious to know where all the figures in the example (p. 19) come from. Are they based on a real project that took place in the past or are they purely speculative and imaginary?
Just asking...
[ April 29, 2004: Message edited by: Valentin Crettaz ]

[Jane Cleland-Huang]

First of all THANKS for buying our book. I hope you enjoy reading it.
Just to provide some context for others reading this post - in Chapter 2 we create two spreadsheets to illustrate the benefits of incremental delivery vs. big bang delivery.
So the question is 'where do the numbers come from?'
First I should say that all of the numbers of the book are derived from our actual experience but due to non disclosure agreements cannot be actual numbers from projects. As we said in the book, the original ideas for IFM originated from a real project in which Mark won the bid for a contract - just because he presented the numbers to the client showing incremental delivery in exactly this way.
Having said that - the numbers reflect very meaningful and realistic values for a large project.
A second thought is also that to convince yourself you should take numbers from any project you may be familiar with and plug them into this type of spreadsheet. You will find that as long as the project can be decomposed into increments that have the ability to deliver functionality early, it is very likely that the returns on your project will be superior if delivered incrementally. I say "likely" because as we show in the two spreadsheets, there are obviously additional costs associated with incremental delivery and these must be taken into consideration. Usually the benefits of early returns far exceed the penalty of additional costs.
btw we have a spreadsheet posted at our website http://www.softwarebynumbers.org under Tools. As a STRONG DISCLAIMER, this spreadsheet has many limitations and is NOT robust (primarily because all the macros etc push the limits of Excel). We only posted it after many requests. It will be replace by Mid June with a more robust java based tool. Also I strongly recommend NOT trying to use the spreadsheet unless you have read the book - because we assume complete knowledge of IFM
Just because each project is different, it really pays to do the analysis for your particular project, in order to determine the best approach and the best way to decompose it and sequence the MMFs.

[Valentin Crettaz]

First of all THANKS for buying our book.
Well, I have just read chapter 2 available from Amazon.com in order to get a feeling, so I haven't bought the book yet.
I hope you enjoy reading it.
All I can say is that I enjoyed chapter 2 so far
Having said that - the numbers reflect very meaningful and realistic values for a large project.
That's what I wanted to hear and, to be honest, I didn't expect less than that from a high-quality book
Usually the benefits of early returns far exceed the penalty of additional costs.
True, but the case may arise where you might not have enough cash to invest even though you are convinced that incremental delivery is the way to go.
Thank you very much for your advice
[ April 29, 2004: Message edited by: Valentin Crettaz ]

[Jane Cleland-Huang]

Usually the benefits of early returns far exceed the penalty of additional costs.
True, but the case may arise where you might not have enough cash to invest even though you are convinced that incremental delivery is the way to go.

However, one of the benefits of incremental development is that it generally requires less upfront cash than a non-incremental approach. The reason being that you only have to fund part of the project and then revenue from early deliverables start to kick-in to offset costs.

[Nicholas Cheung]

In addition to cost, will we consider any returns from the software?
If so, how we recongize the returns? in accural basis or what?
Also, does the returns be consider iteratively as well?
Nick

[Mark Denne]

In IFM, returns are ascribed to each and every MMF. The returns can take many forms ... revenue, cost savings etc. The returns are presented as a cash flow. This is discounted and summed in the usual way to calculate a net present value (NPV). Because the returns are time sensitive, the net present value of an MMF varies according to where in the development sequence it is developed/delivered. For this reason, IFM calls these values "sequence-adjusted net present values" or SANPVs. By default, IFM uses these metrics (or more precisely a weighted version of these metrics) to optimize the overall development process for maximum net present value.

[Nicholas Cheung]

Hi Mark,

Because the returns are time sensitive, the net present value of an MMF varies according to where in the development sequence it is developed/delivered.

In this sense, when should we carry out the process iteratively?
Whenever there is a revenue generated? or we do it in a regular time basis?
Nick

[Valentin Crettaz]

Originally posted by Jane Cleland-Huang:

However, one of the benefits of incremental development is that it generally requires less upfront cash than a non-incremental approach. The reason being that you only have to fund part of the project and then revenue from early deliverables start to kick-in to offset costs.

I understand your point very well. Let me rephrase.
Let's admit I'm totally convinced (and I really am) that incremental delivery is the way to go. No doubt about it... Actually, I'm convinced of the IFM approach since ever (even before I got to know your book).
In my planification (real past case!!), I have identified two MMFs which needed approximately there months to complete. They could more or less be done in parallel but this isn't an option since I had only one developer working for me and I couldn't allow myself to hire another one. So, I have decided to develop one MMF and then the other one. Obviously, I chose the one MMF whose ROI was bigger, makes sense. The problem is that my budget was so tight that I couldn't even start the work on this first MMF unless I had found other financial solutions.
Agreed, this is a worst-case scenario, but s**t happens and you have to deal with it. All this to say, that sometimes even great ideas like IFM may not be the proper answer to certain problems.
[ April 30, 2004: Message edited by: Valentin Crettaz ]

[Ilja Preuss]

Originally posted by Valentin Crettaz:
In my planification (real past case!!), I have identified two MMFs which needed approximately there months to complete. They could more or less be done in parallel but this isn't an option since I had only one developer working for me and I couldn't allow myself to hire another one. So, I have decided to develop one MMF and then the other one. Obviously, I chose the one MMF whose ROI was bigger, makes sense. The problem is that my budget was so tight that I couldn't even start the work on this first MMF unless I had found other financial solutions.

What might sometimes help is to think about wether the MMF *really* is minimal. For example, sometimes you might simply be able to get more funding by being able to show stakeholders a partially working system.

[Mark Denne]

A great point! Identifying MMFs is both a science and an art. We've included a whole chapter in book on this subject. In addition to being Marketable, and a Feature, it also has to be Minimum

[Valentin Crettaz]

Ilja and Mark,
Thank you for your pertinent comments about the *minimal* (and often overlooked)aspect of MMF

[Ilja Preuss]

Originally posted by Mark Denne:
A great point! Identifying MMFs is both a science and an art. We've included a whole chapter in book on this subject. In addition to being Marketable, and a Feature, it also has to be Minimum

I think what is critical here is the definition of "Marketable". Defining it as "Marketable to the end users" might just be too limiting. How do you define it in the book?

[Jane Cleland-Huang]

Actually we define the term "Marketable" is something with intrinsic value to the user in terms of revenue generation, cost savings etc. This term captures the "value" part of the equation.
In retrospection I think that in some organizations another term might capture this better. ie some organizations aren't 'marketing' services but are focused entirely on different types of value. A Minimal Valuable Feature perhaps, but of course this doesn't sound as good as MMF
[ May 03, 2004: Message edited by: Jane Cleland-Huang ]