This concept can be viewed another way - as a chronology or evolution of systems. A system enters its life at some point in time. In the below diagram some have begun their life prior to say, 2006. Others entered their life after 2006.

You will also note that the system will commence life as being in use (green), then at some point start to degrade (yellow), then become critically degraded (light red), until finally it is obsolete (red).

When looking at this life cycle, there is a point or period during which the opportunity to replace, upgrade or accept the system will move to obsolescence is apparent. This is what I call the "replacement/upgrade window". Once the system moves beyond this window, then you have a degraded performance or output from your system.

BUT....a "vehicle" is needed to manage any "transition" of these systems. In other words, a mechanism is required by which a system is moved from a "degraded" state to an "upgraded" state and hence back to "in-use". If the system is being replaced then the current system is permitted to degrade and then is removed from the organisation in some way and a new system is purchased or to keep the same parlance - moved from a "non-existent" state (i.e. the organisation does not have the system) to an "in-use" state. This is the responsibility of the "mechanism" I have mentioned.

This leads into "defining a project" in my next post.