Upgrades? You want ‘em? Do you want ‘em?
Well they can be trouble-some can they not? A good reason to avoid too many of them maybe?
Yes and no.
We all have experience of suppliers and their concept of upgrades. Microsoft seem to think we don’t really mind totally relearning what we have all been doing quite productively for the last ten years, while others are maybe more plugged in to how we really use our software.
Housing Management Software as an application is quite specialist, what used to be referred to as a vertical market. You know like a 1970’s 13 flight tower block. (Well maybe not). Now in this case, your contract may stipulate how often you take and install an upgrade. You may well invalidate your support contract by not upgrading. If unsure why not dig it out now.
Your housing software provider may be keen for you to keep up with the latest version. There are a few reasons for this. More recent bugs should have been ironed out. Although take care that one persons ‘bug’ might actually be another’s ‘feature’. Also, if your supplier is attempting to support several versions of their software, that creates delays in supporting your issues and you will quite often receive fault resolutions of the ilk of ‘Bug resolved in version x.y, please upgrade your software at the earliest opportunity’.
So its essential to understand why you are upgrading at all:
- To tackle known bugs that are causing you problems
- To have access to improvements
- To access RFC’s (Request for changes) your organisation has purchased
For the last category, remember that you can always request your supplier back fit any RFC’s to your current version. Paddy Power would give me poor odds if I was to bet there would not be a £charge for that, but it may well help you avoid the issues an upgrade may cause you. Also you need to have trust that your supplier will make it function identically in your current version, as in a future version you may upgrade to.
Conceptually, there are two styles of housing software, package and bespoke. In theory, a pure package application should be a less painless upgrade. Where bespoke is involved, it is usually very problematical to attempt any kind of upgrade. The ideal situation is a package solution where bespoke local elements can be defined. IE functions, views, SP’s, workflow etc, which can remain untouched by an upgrade. Bear in mind though, if you are feeling smug, your bespoke elements may still be affected by dropped objects or restructure in the upgraded schema.
So it is essential to determine the effect of your upgrade, fully before attempting to go live with it. Start with the detailed amendment list from your supplier. These should be graded in severity. IE Essential, action needed ; Important, checks and possible action needed; Optional or cosmetic. Apart from the detail, a summary is tremendously useful for end user departments. Summary in plain English can be ideal for working out what to switch on and what can be ignored.
In a technical sense too, information on new DLL’s needed on Windows or other dependences, like particular versions of the .net framework are essential. Sites running multiple Citrix or other thin client infrastructure will need to test and deploy these elements, confirming compliance with other software on those servers. Your finance team will not thank you if your housing system upgrade renders SunAccounts unusable for a week or so.
Apart from what is shiny and new, bear in mind it is essential that all your existing processes will still work. So some resource should be allocated to that too. By now, you are probably realising why you don’t upgrade so often. You may be a beta site or feel that your organisation is or needs to be seen as a trail blazer. While that is certainly a good way to make your supplier take notice of and mould to you, it does carry some risk.
Utilise your user group (or user group contacts privately), to find out who has upgraded to your target version and what problems they have encountered. Ask as many organisations as you can and be sure to do the reverse too. Help them to help you.
You can of course pay your supplier to have a resource with you to make the upgrade go smoothly. This can be a good investment if it achieves that aim. If you end up with 40 housing staff doing nothing for a day or so and you have followed that approach, it’s fair to say you should be reaching for the pen to write a very strong letter. Your users will be blaming you and your IT department if it goes wrong, not necessarily your software suppliers.
The worse story I ever heard was of an organisation that reputedly lost a whole six weeks as a result of an upgrade. I gather they wrote a letter, but even more dramatically, they went to tender before the year was out, excluding the incumbent supplier. As I have said above though, how you handle upgrades is important too, most suppliers will do their best, work with them and importantly resource your side properly.
Having been a user, IT Manager and MD of a major Housing System Supplier, boringly, you would always see me upgrading after the herd. After the first point or bug release. The IT equivalent of not being a pioneer, but following later with the women and children in the covered wagons. From the cowboy films I recall, it’s generally the pioneers who tend to end up with the arrows in their backs.
Read on to, Never satisfied, how to keep pushing your systems forward:
If it aint Harder, Better, Faster, Stronger, should you be upgrading at all?.
(c) Tony Smith, Acutance Consulting www.acutanceconsulting.co.uk
File Under: 360,1stTouch,4Js,Aareon,Academy,ActiveH,Alignment,ALMO,Anite,Apex,ArchHouse,Archouse,asbestos,Asprey e-state pro,Asset Management,Aurora,Average IT Costs,BO,BPR,Browser Applications,Business Objects,Business Process Review,Business social networking,Castle,CBL,Cedar Open Accounts,Change,Cheaper Housing IT,Chics,