Application of IFM - Incremental Funding Method

Teodora,

why not ask the authors for more background?
Jane Cleland-Huang is on LinkedIn. Did not find M. Denne there though.

What they say in the paper, that the stringent SW development process (which strengthens the belief that estimates can be met) should be extended to include value-finding and more ambiguous activities like BA. As consequence, customers will accept this ambiguity and not ask for a budget estimate. Hmm, not sure it works.

"We can accomplish this only by positioning software development as a value-creation activity in which business analysis is integral."

For me it also comes back to the point of a project being seen not as a creativity exercise but more an execution task. Which again contrasts with a program.

Thomas

Keith,

I understand this method, and as you mentioned other cost-driven methods, as an additional tool when evaluating new ventures/initiatives. Sometimes good ideas and strong business case are not a recipe for a success.
Do you have a particular example? I am looking for a project/case study where this, or similar methodology, has been applied.

I don't know of any published case studies offhand, but have lived through a couple that I can describe at a high level.

Software development, or implementation/modification of COTS software is usually dealing with a modular system with different functionality in different modules. For example, a CAD system might include solid modeling, specific modeling features that support special types of manufacturing, stress analysis, kinematics, and other tools in a larger toolbox.

At the outset, the stakeholders who bought onto the whole plan are touting how all these features are going to transform the engineering dept. Functionality that seems like it would be simple to implement, may actually require significant work to either customize the software, or other parts of the business system to make them work, and the business case might not add value over existing processes.

As the implementation progresses, the net present value calculations change based on the current understanding of both cost, and value after implementation. The final configuration implemented will often be quite different than the original sales pitch. Some items may be deferred until later if funding is not available, or until some prerequisite functionality is available.

As they say, the devil is in the details, and the details often aren't known until you dig deeper into the problem. Then the financial rationale changes, driving changes in priorities.