hello writers, After studying business and moving into the software industry (at least the last 8 years) I get the idea that most of the projects are not thought through very well. e.g. internet only banks starting just after the hype. buying the most expensive product beacuse marketeers of that product are better. Would this book be of help to managers who can then see how to organise a project and save money and time
swimming certificate (A & B), shoelaces diploma, and some useless java ones.
Well I guess I can best answer that question in two ways. First of all IFM provides the type of insight into a project that enables a manager to manage a project much more effectively. The shorter incremental deliveries are more controllable than a 'big bang' approach to delivery. In fact the famous Standish Chaos report on failed software projects identified project size as a major factor contributing to failed software projects. By decomposing a large project into a series of mini-projects (ie MMFs) we already dramatically increase the likelihood of a successful project. More importantly, if you are familiar with Ed Yourdon's work on Death March projects, you will recall that death march projects have a tendency to just 'run away' without any realistic go/no-go decision points to get the project back on track. IFM provides natural evaluation points along the way. Prior to each iteration (ie starting a new MMF or MMFs), the manager gets a clear indication of how the project is doing and can reassess how to proceed. The proposed initial delivery sequence of MMFs is certainly NOT carved in stone. The manager, developers, customers, and business stakeholders must all be involved in assessing the project prior to each iteration. Just to illustrate the perceived benefits of IFM to project management....One of my grad students works for a major industry in the Chicago area and he introduced "Software by Numbers" to his boss (OK - he definitely earned some brownie points from me!). Anyway, his CEO then bought books for each manager in the organization and asked them to start applying IFM practices to their software projects. This is just one example, but I think it illustrates the percieved usefulness of IFM to manage projects more effectively.
Jane Cleland-Huang PhD<br />DePaul University<br />firstname.lastname@example.org<br /><a href="http://facweb.cs.depaul.edu/jhuang" target="_blank" rel="nofollow">http://facweb.cs.depaul.edu/jhuang</a>
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.
Author - Software By Numbers<br /><a href="http://www.softwarebynumbers.org" target="_blank" rel="nofollow">http://www.softwarebynumbers.org</a>
Originally posted by Mark Denne: IFM allows you to test if you've properly thought through the project from a financial perspective.[/QB]
I'm very eager to get my hands on a copy of your book. Your statement here sums up what I see as the great value of what you've described. If I can describe the impetus and the progress of the project from a financial perspective, then that helps me help the customer decide what is necessary to implement, helps me show the real value of the project internally (I work for a software development company), helps me then justify resource requests, etc, etc. Things that were just nebulous statements before, like the software must be developed with these features before X date, should now be able to be looked at from a ROI perspective. Then I can aid the customer in deciding the true impact if the feature set should change or the date should change or ...
So here I am a software guy using this approach to help a customer determine what features to implement first (along with other criteria such as schedule, criticality, etc). Will I need help from a financial person to do a good job of applying MMFs?
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
Originally posted by John Wetherbie: Will I need help from a financial person to do a good job of applying MMFs?
Well, I guess you somehow need to find out the value of every MMF. A "financial person" would probably be of great help?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Feb 28, 2004
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.
Joined: Jul 11, 2002
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.
I did mean that is was not thought through out of financial and marketing perspective. As a developer or architect you just create a design, and implementation and you do as asked. To be fair, you have to make a living. Don�t get this out of context, obviously i will object to a certain degree if it does not make sense at all, but in the end you are doing it for a customer. At a second thought, not thought through, may mean design as well. For example you are creating the most wonderfull design build for reuse and expension everywhere, but.... the reuse and expension never happens. What i see happening is that software architects are creating good designs, but are not thinking about the customers needs. So in that case that might be another case of not thought through. anyway thanks for the elaborations. friso