Evolutionary

Of course some of the good ideas, the wild cats, will not take off. Some of our star products will be replaced by other new ones. It may be decided not to carry on milking one of the more mature products but to replace it instead. What all this means is that it is quite likely for a product, particularly in today's market, not to follow the normal life cycle but to be dropped at and earlier stage.

Contrast the classical cost curve with that in the second graph. Here the costs of developing the system are staggered over time. This stepped approach is beneficial in that it gives a faster initial implementation and also minimises any potential losses should the product be dropped.

It is all very well showing fancy diagrams and applying the terminology of management consultants. But how, in reality , can all these concepts be used in today's systems development environment?

More windows

In the following diagram points on the time axis represent the potential delivery dates of the required computer system. The value curve indicates the total value which the system would produce if delivered within a particular time scale. As can be seen, the longer it takes to actually deliver a working system, the shorter the life span (as determined by the product's window of opportunity) and thus the less overall value which can be accrued.




Now we can see that there are very real constraints on the system, if we do not deliver within the 'window' then there is no point in continuing. It is not a question of pushing systems to do the impossible, but more a case of pushing systems to make the correct decisions about design.
The cost curve on the graph indicates how the cost of development rises as the time taken to deliver increases. This increased cost is a result of the additional payment of salaries, accommodation, overheads, hardware resource, etc. The earlier a system is delivered then the greater the difference between development cost and the overall value, that difference indicates the total benefit of the system.

One important aspect which should be noted when considering the costs value curves of the systems, is that part of the graph to the right of where the two curves cross. It is at this point that systems will not recoup the development cost during their lifetime, a situation which has unfortunately been all too common in the past. The worst offenders in this area are those systems which are developed and enhanced to aid functions in the dog stage of their life, or alternatively support activities such as personnel etc.

How can we use the ideas which we have discussed (on product life cycles, ranges of options, and cost/benefit curves) together in a way which will enable IT departments to provide the most appropriate solutions? Well, one important fact to be noted is that we could overlay our range of options onto the cost value graph. What this overlaying shows is that the perfect solution is also the most expensive , the one which would take the longest time to implement and therefore the one which will have the smallest overall benefit ( if it manages to stay on the positive side of the equation at all).
If, in addition to the options and cost values, we now consider the product life cycle - we can begin to see the way in which all the concepts discussed can come together in a coherent form. The first of the diagrams which follows shows how the classical product life cycle will typically evolve with time as measured by the vertical axis. Onto this life cycle we have overlaid the costs as they are typically applied. In this case a perfect or near perfect solution has been sought, resulting in a long delay before possible 'stardom' can be reached. In addition to the time delay, there is also the fact that the full cost of the system has to be borne.