Saturday, July 29, 2006 10:20 AM
In this post I’m going to discuss a possible solution to a common problem and that is how do to initiate a renewal process to replace an old system without initating one of the existing major change drivers.
System renewal and end of life are the life blood of I.T. Our whole business thrives on change. But change is costly, time consuming, complex, problematic and uncomfortable. It’s one of mankind’s ultimate ironies, we are good at adapting to change but we don’t like it.
So the change drivers for a system are most commonly,
1) Change in business requirement
2) A technical reason
The main problem with these change drivers is time. Here are some for instances;
Business requirement change needs to cater for it in a timely fashion to take full advantage of a market change.
A fundamental piece of the puzzle, either hardware or software has gone wrong and a solution is sort expediently as the business is no doubt suffering without it.
As you can see the main change drivers are in the short term and give little warning not allowing much of an opportunity to plan and budget.
It is a pretty much well known fact that we dislike short term change, frankly it is a pain in the arse.
Pushing as much out to the medium and long terms allows you more time to plan but the common change drivers will always be there so the challenge is to minimise the impact of them by using time as a change driver.
My idea is to place a ‘used by’ date on to the different parts of a system, this in effect will then become a change driver. Categorise the impact of change on that part (which can simply be ‘major’ or ‘minor’ for instance) and place a date for review and the initiation of it’s replacement before the ‘used by’ date into the Service Level Agreement (SLA) as part of the design stage of the system or after major review so the businesses expectations are managed.
We understand the ‘used by’ date on our food products, we understand that there is greater risk involved in eating meat or drinking milk after this date so adding this to our systems will in effect do the same thing.
Having a used by date allows you to have items on your budget instead of a blank piece of paper at the start of a budget round. It allows you to have a longer term view so you can manage resource over a great period of time.
So how do we establish a ‘used by’ date? The most obvious way is for the ‘used by’ date to mirror the products support end date. Other generators of ‘user by’ dates are dependencies on other systems or processes, or when it has served its purposes such as a projects-end.
Having many ‘used by’ dates in a system gives visibility to the fact that a system is made of many constituent parts working together so the dependency between them is understood. Parts can be replaced but categorising the part manages the expectation of the work involved to replace it.
The temptation is to just have one ‘used by’ date which can be the earliest major ‘used by’ date in the system as it simplifies the understanding. The problem here is that you could prematurely be shortening the life of the system. It could be after all easier, cheaper and les complex to affect a major change than replace the whole thing. The ‘used by’ date system can be used as means to maximise the life of a system.
Like all things systems have a life, accepting this fact allows you to cater and manage its renewal. The ‘used by’ date is an easy to understand tool to help you initiate this process.