Mark Denne

I'd like to add my thanks to Jane's and say we really appreciated the quality and range of the discussion. Thank-you, each of you, for raising questions and for contributing to the answers. Congratulations to our book winners! We'll indeed be hanging around the ranch for a while to answer any remaining questions.

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

This is an excellent point. Understanding how the financial decisions are made helps us as developers and architects to have a wider understanding of the context in which we are operating. However, the advantage of IFM is that it empowers you to actually contribute to those decisions. If the financial analysis is performed with the developers and architects at the same table as the stakeholders and the marketeers, this not only serves to breakd the divide of understanding and vocabulary but also provides better and more informed decision making for all parties. The result is a more coherent team and generally a more successful project.

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.

Part of the elegance of IFM is that it treats AEs and MMFs equally. In other words, it's just as sceptical of doing the work associated with an AE as it is of an MMF. Whether it's an MMF or an AE, it has to emerge as the most compelling thing to do now (in comparison with everything else that could be done) in order to be the action recommended by the IFM heuristic.
This means that to a large extent we've transcended the traditional religious arguments about Architecture (should we do it all up front, or should we just do bits of it as and when needed?) that often characterize the debates between adherents to traditional and Agile processes.
By applying the same rules to AEs as we apply to MMFs we've ensured the same financial analysis and justification is demanded of Architecture as all other aspects of the project. At the end of the day, it allows us to answer the question "should we do all the architecture up front?" with a dollar figure - a monetary gain or loss against doing it "just in time".

An excellent reply from Jane as always
After reading your post it raised in my mind the question of what you mean by "thought through". Sometimes projects are very well thought through from a design and analysis perspective, but they're not well thought through from a financial perspective. Take the example you mentioned of the internet banking portal. It might be the best and most elegant design in the world, but if it doesn't generate the revenue necessary to sustain the project, it will just die, or be implemented only partially.
This is where IFM comes in. It allows the financial design to be scrutinized and modelled to the same level of rigor as the technical design. Sometimes as architects, designers and developers, we take it for granted that this has been done, but find to our suprise that it hasn't been. And sometimes we forget that architectural or design decisions we make can have a big impact on the project's financial success and therefore its viability.
So I liked the way you asked the question. Maybe it's a good way of putting it. IFM allows you to test if you've properly thought through the project from a financial perspective.

To John Wetherbie's point, IFM provides the analysis necessary to provide a "financially informed" answer to the question "what should I do first"? One need not follow IFM's advice of course (clearly, there is always the flexibility to do "A" first even if doing "B" first is what the IFM heuristic recommends), but if one does decide to do "A" first, the financial impact of that decision is visible and quantified when IFM is applied.

It's an interesting question, but not one that IFM directly addresses. It is however the case that IFM provides both the model and the metrics to quantify the impact in financial terms of the decisions to advance (or delay) the implementation of a feature, as well as to understand how the value of a feature changes with time. We describe IFM as a "financially informed approach". It does not dictate a particular conclusion, but it keeps you informed about the financial impact of the various development options open to you.
One thing to stress is that IFM is not a development methodology - like RUP or XP/Agile. Instead IFM is compatible with either approach (there are chapters dealing with each in the book) and augments your chosen development methodology by providing financial rigor to the sequencing decisions.
As an aside, one interesting approach to managing outsourcing is to consider the situation in which the design can be "executed" directly. Take a look at the "executable UML" approach by Gorilla Logic at http://www.gorillalogic.com.

The table of contents on Amazon.Com can be found at:
http://www.amazon.com/gp/reader/0131407287/ref=sib_rdr_toc/002-9901654-7464003?%5Fencoding=UTF8&p=S00C#reader-link

Well please feel free to take advantage of the opportunity to ask any questions while we're here. It's good to know that our book has enlivened the forum - at least temporarily

Hi Warren,
Good evening! I think it's about time I replied to some of these posts Jane's been doing all the work today so far. I've had some meetings in the office which have prevented me from getting into the forum until now.
Amazon has kindly published a table of contents (as well as a sample chapter by the way). You can find the table of contents here:
http://www.amazon.com/gp/reader/0131407287/ref=sib_rdr_toc/002-9901654-7464003?%5Fencoding=UTF8&p=S00C#reader-link
Regards
Mark Denne