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 ]

Is there a software development organization that is already using MMFs and IFMs.

Yes - we know of several organizations that are adopting at least some of the IFM practices. I'd have to say though that we are still in the period of "early adopters". We are hoping to expand our website shortly with testimonials etc of these early adopters. IFM is a win-win situation, because it provides you with an analysis that means you only follow the approach IF it makes sense for your project.

b) Most traditional product companies in their first release try to include the bare minimum features that are sufficient to sell the product. In future releases they attempt to add more fancy features. In this sense are all these companies using MMFs and IFMs.

This is true, and in fact in the book we specifically point out that the idea of incremental delivery is certainly not new. What IFM offers that is new, is the ability to reason about the financial impacts of different incremental breakdowns and delivery sequences. For example, you could compare the benefits of a linear development schedule, vs. a concurrent one, vs. a hybrid approach in which you gradually ramp up the work. The new thing about IFM is its ability to inform us of the impact of those decisions.

As its the end of the week and therefore end of our book's promo at JavaRanch, I wanted to take the time to say a big THANK YOU to everyone who welcomed us to this forum and who participated in the discussion.
You were all great and we enjoyed the discussion. I'll continue to visit the forum in the future.
Good luck with the book contest!
[ April 30, 2004: Message edited by: Jane Cleland-Huang ]

Vasu, this is a great question and probably the one that we have been asked the most since the launch of Software by Numbers. The answer is that we don't expect developers to be experts in this. What we do hope for is closer collaboration between software developers and business stakeholders (customers that understand marketing, financiers, business managers etc). It is these stakeholders who bring input on the value side of the equation.
IFM is only made posssible in presence of this type of collaborative effort. However the rewards can be significant.

The terms MMF and IFM are both new - although of course Mark and I are both pleased to find that they are starting to be adopted as terms in peoples' conversations.
In writing our book, we felt that the new focus on software development as a value-creating activity was best expressed through the introduction of some new terms.

Well I have to admit that I haven't read this book. Could you give a brief synopsis?

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.

I was just looking through this thread - and I realize it is NOT an IFM thread (and I was trying to be a little sensitive and NOT try to bring IFM into every conversation)... however I would like to raise what I think is a relevant point.
If management see the financial benefits of iteration - then they will do more than preach it, they will buy into it. IFM provides a strong financial rationale for iterative development, because iteration is an underlying principle for incremental delivery.

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.

We do include lots of examples in the book. In some cases to explain a concept we just use generic terms such as MMF A, MMF B etc, but then we also have a fairly extensive set of real examples. In fact we use a series of short examples throughout the book to illustrate IFM, and then the final chapter provides a beginning to end case study of applying IFM in a banking portal application.
As you point out, our audience is broad and covers developers, customers, CXOs etc. However this reflects the fact for an organization to successfully manage software development as a value creation activity it requires buy-in from all of these stakeholders.
As far as CXOs are concerned - our experience so far is that their response to IFM is very positive. As I mentioned in the Managers thread, one of my students gave a copy of the book to a CEO in this company. The CEO's response was, "this is how I want our company to develop software in the future". He then bought copies for all of his project managers so that they could apply IFM principles on future projects. So far we have only had positive responses from CXO's who have read Software by Numbers.
Although CEOs may not necessarily understand some of the technical aspects of the book to the same level as the developers, they certainly seem to get the intended message - that IFM is a new way of going about the business of software development.

Yes... IFM requires collaboration between many different types of stakeholders. Developers determine cost to build an MMF, but you absolutely need the impact of 'financial people' such as marketeers and business analysts to project the revenue for each MMF. Its definitely a team effort.

Do you already have any experience on how often the analysis tends to suggest upfront development of architecture in contrast to just in time development?

I think we would have a hard time quantifying that. We can observe specific types of project in which upfront development makes sense. For example if the requirements are relatively stable it may make sense to build a slightly more extensive architecture upfront to save refactoring costs later. However this is VERY different from building the entire architecture up front.
We actually advocate upfront architectural design, but incremental development and delivery.

Well if AE1 is dependent upon AE2, and MMF A upon AE1 then it implies that MMFA also needs AE1. If that is not the case then it would probably indicate that you didn't do a sufficiently fine-grained decomposition of the AEs. The idea is to decompose them sufficiently so that you only invest effort developing those parts of the architecture that you need for the current MMFs.
There are two approaches you can take - depending on whether you are in an agile or a non-agile project. For agile projects you can create AEs as you go! (ie no big upfront design). For other projects (and certainly this can also be done in agile projects too), you can design your architecture upfront according to the MMFs that you plan to build in the near future, but you can then decompose the architecture into AEs.
In either case, if you want to optimize the value of your project you should only build AEs as they are needed.

Initially we only had the concept of MMFs. We thought we could decompose a system entirely into MMFs. An MMF obviously costs money to construct but also returns value - so it has both costs and returns.
However then we discovered that sometimes two or more MMFs both need the services of something that we can consider a physical implementation of the architecture (ie an AE) - such as a secure messaging system. So this created an analysis problem. Which MMF should we attach these AE costs to? Obviously they belonged to whichever MMF we ended up sequencing first.
From a process perspective it therefore makes sense to recognize AEs as valid elements to be built and sequenced. Our IFM heuristic works in such a way that an AE would NEVER get scheduled until it is needed by at least one of the MMFs because an AE doesn't provide any useful functionality on its own. It is useful ONLY because it supports the user requested functionality of the MMF. In other words secure messaging is ONLY important as it supports functionality such as an ATM user requesting information about their account balance or to support the user in transferring funds. Because an AE doesn't return value on its own - we see it as a cost incurring element, drawn into the sequence as and when it is needed by an MMF.

Sure.
MMF stands for Minimal Marketable Feature. It is best described as a "chunk of functionality" or an incremental delivery of part of the product you are building. An MMF is characterized by its ability to return value to the customer, where value can be measured in terms of cost savings, revenue generation, or a number of less tangible factors such as increased brand recognition, increased customer loyalty etc. We therefore deconstruct a product that is to be developed into these MMFs.
A related term that we haven't mentioned much in this forum is an Architectural Element or AE. An AE is similar to an MMF except that it is cost incurring but NOT revenue generating. Typically an AE is an element of the architecture that needs to be delivered in order to support the functionality of an MMF.
Finally, IFM stands for the Incremental Funding Method. IFM is a process and related concepts and heuristics that we use to sequence MMFs and AEs in order to optimize the value of the software project, where value is measured in terms of the financial metric known as Net Present Value (NPV). The idea is to identify the delivery sequence (which can be linear or concurrent) that meets the needs of your organization.
THe primary goal is to optimize project level NPV, but we may also be interested in manipulating other metrics such as the initial funding investment, time to reach self-funding (ie when the income from earlier MMFs funds ongoing development), and break-even time (ie when the income from earlier MMFs has paid back earlier investments).
In Software by Numbers we provide an introduction to this type of financial analysis and describe how to apply the IFM approach.