June 20, 2008 at 4:58 am
Guys,
i would like your participation and opinion in the above subject. Please think of it not only from a developers point of view. Suppose you were an IT manager, and, your company uses (for example) an ERP program, that is critical for your financial operations.
A new version comes out (not beta), that may provide you things that you are thinking that would be usefull for your company. Should you be an early adopter, or should you wait a reasonable amount of time, observe problems if any and then proceed to the upgrade?
What are the risks involved, and what are the drawbacks of delaying an upgrad of software in your company? What would your decission be?
June 20, 2008 at 5:14 am
You have to weigh up the benfits the upgrade brings to the business against the risks assoicated with going with a new product...so the answer as usual, is "it depends"
It can depend on the nature of your business? Is this risk a viable one?
It can depend on the software and supplier of it? How have previous upgrades gone? has there been many bugs?
What benefits does the upgrade bring to the business? If the benefits are vast then it may be wise to upgrade, if not then it may be benefical to weight for a product that you know is stable.
Gethyn Elliswww.gethynellis.com
June 20, 2008 at 5:29 am
Where I last worked, we had one person in charge of the ERP - implementation, testing, training, dealing with the vendor, everything. We never went early adopter for that reason.
I think unless you have a group of people that can dedicate themselves totally to this upgrade, wait and find out what other companies are saying re. the new release. Or put it in a testing area for people to try out and arrange testing sessions with various departments well in advance. I guess what I'm saying is to be an early adopter, make sure you have more than the amount of people you think that you would need for support.
June 20, 2008 at 5:40 am
June 20, 2008 at 6:19 am
It's just a straight-forward cost/benefit analysis along with risk and mitigation. Do you need the new functionality or is it nice to have? You need it. How big is the upgrade? Is it a simple patch that can be run in the middle of the business day or is it a major enhancement that requires taking the servers off line and upgrading the database? There are more questions like these, but you get the idea. Once you determine that you have to have functionality 'X' or the business will tank and you determine that it's a huge update, you begin to work on mitigation processes. Plan for installing the upgrade two weeks (or more) out so you can alert the users that the change is coming. Test the deployment multiple times, using copies of the production machines and databases. Be sure everyone involved knows how to both perform the install and perform a rollback. Make sure your key support personnel don't start vacation the Monday after you roll out and don't roll out the day before a holiday (I've lived through that one, not fun).
These are the kinds of decisions that should be made all the time. If you're either NEVER installing updates or ALWAYS installing updates without this sort of process, you're doing your job wrong.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 20, 2008 at 9:39 am
The ROI or cost/benefit is something you have to determine, but I think there's something else to consider.
Is your company a risk taker?
Going with a new version early, means you're somewhat an early adopter. If this is counterintuitive to the way your company, and especially the IT department, adopts software, don't do it. Did you adopt Vista early? XP? Office 2007? Firefox 1.0?
There's a fundamental way in which people's attitudes are shaped about software. Some people love diving in early, dealing with issues, solving problems with workarounds, etc. Others hate it. If your culture embraces that, then I'd look at the new version.
the other thing is that even bleeding edge, early adopting companies don't do every new version of software. They can only handle so much instability, so they may upgrade a few pieces of software early, wait on others since they're dealing with problems in say Windows and don't want to tackle Office.
June 23, 2008 at 8:13 am
there was an article in CIO magazine a few years back about how AT&T tried to implement a new CRM system and it was a total failure
CRM/ERM apps are such monsters that it usually doesn't make sense to upgrade every version. They cost a lot and there are a lot of development costs as well as time.
where i work we have an internally developed CRM/ERM app. really a collection of a lot of apps that share a lot of common code and access the same databases. there is a major release once every few years and a lot of "point releases" like the old Quake patches that fix bugs and add new features as requested by users and customers
June 23, 2008 at 8:25 am
Thank you all for your replies.
I still read them, and this "survey" is valuable to me.
500, bear in mind that we are discussing the upgrade of an existing software to its latest version and not the installation of a complete new software, that did not exist before. Many many cases of ERP (check ERP in TOSCO - Whirlpool, etc) or CRM as you say have failed.
(99% of the times, not due to software's fault. Rather, due to innapropriate software selection and bad project management, allocation resources, etc etc).
June 23, 2008 at 10:35 am
My theory on upgrading is to wait about 6 months after a product comes out, then start to the work needed to upgrade.
But, it all comes down to how badly you need anything in the upgrade. I have done day 2 upgrades, I have had systems that almost never got upgraded. Day 2 upgrades where usualy when we had waited for a particular feature in a new version, and maybe even internally developed against the beta version of it.
It's a fine line to walk though. Don't do enough upgrades, and at some point it becomes almost impossible, if not impossible at least impractical, to upgrade. CRM applications seems to be one of the hardest if you get stuck with an older version since there is so much customization going on in them.
June 23, 2008 at 3:54 pm
It all depends on "RISK" I have worked for companies with top-line support from Microsoft and They ofcourse would work with the bleeding edge releases. For those others that had to go through "channels" is a very different story and they would move only after SP1.
* Noel
June 26, 2008 at 11:21 am
As a developer, my favorite part of my job (and sometime most frustrating) is testing and debugging. On that note, I would get upgrades early on certain conditions. 1. Depending on the scope of the program, is the company able to setup an isolated test area for the program? 2. Is it something that I can install on my local machine that won't affect anyone else? 3. Is it a program that is developed in house? If I am in a position to help another team test something, I definitely will.
As others have mentioned, there are a lot of "it depends" for this type of thing. For larger programs, like ERM, my preference would be to wait at least a few months and see what is being reported in the industry (unless it could go in a test area).
I am surprised no one has related this to upgrading SQL Server. That has been a frequent topic and I think it relates to this question. Something Grant said about need to have it or like to have it brings up the question, is this upgrade something that could wait until the next version (i.e. not upgrading from 2000 to 2005, but waiting for 2008).
Ian.
"If you are going through hell, keep going."
-- Winston Churchill
June 27, 2008 at 12:56 am
First, i would like to thank everyone for their reponses.
I have the same opinion as most of us here... It depends, on the upgrade benefits, and of the "state" the company is in. "State" meaning how stable it is, how many other projects are running, business seasonality, support, other customers opinion of the upgrade, etc. The best thing for us, would be for to build a critical success factors, or should i say critical upgrade factors, in order to evaluate and prioritize our concerns.
Anyway, the reason i asked is because our "brand new" IT manager (God made him IT manager) he literally shouted the following phrase; "IF i hear ever again that we shouldn't upgrade to the latest software version (regarding our ERP) i will jump off the Window!!!" This was also embraced by our "brand new" MIS manager ( a previous sales person), how came to me and said, "did you listen to that??", because a i expressed my concerns, that our company should rather wait or consider very very causiously before upgrading. Because of various reasons. a) Brand new IT manager, with no competence whatsoever of supporting any of the system we have, b) brand new MIS manager, who id rather not say, but cant distinguish between Olap - Cube - ODBC driver, what is the difference, and c) because we are in such a position that nothing works as it should in this company....
Excuse my long answer, any way i am going to jump off the boat, before it sinks. I was just wondering if i was so wrong about the whole matter...
Regards,
Dionisis
anymore opinion on the subject, welcome...
June 30, 2008 at 6:31 am
Yeah, I have to agree. A blanket statement like that is not good.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 5, 2008 at 10:06 am
Hi to all
First of all I would like to say that I fully sympathize with your problem and I can only judge from my experience so far in the field.
As an IT manager gone through several version upgrades in various forms in different companies I have a very simple set of rules that one should use to make the choice or not.
1) Business Engagement - Is there a direct and clearly identifiable involvement from the business? Are there super users who will support and will be able to verify results etc
2) Are the Functional and Operational benefits presented to the business justify the upgrade?
3) Are there any Change Freeze periods set up within your organisation that will be affected by this upgrade?
4) Has a User Acceptance testing being prepared and agreed with above? (ie who does what, who signs off the functional tests etc)
5) Has regression testing being agreed as part of the above?
6) Can you do parallel testing?
If any of the above questions is no then the answer is NO GO.
Having read all the replies including yours I think it is these kind of people that give the profession a bad name. As far as the difference between olap cube and ODBC driver goes I have no answer apart from the old question in the book: Which goes first?
Panos
Plan - Evaluate - Organize - Summarize.
August 6, 2008 at 12:57 am
Panos,
thank you very much for your response. I fully agree with your opinion.
and since i suppose you are also Greek, I have to say that, I so much miss working for a company that does things properly, as i did once in the past. Unfortunately, companies that operate with responsibility and knoweledge and by the book, in Greece, can me counted on the fingers of my hands... Not to be missunderstood, by the book means your moto... Plan - Evaluate - Organize - Summarize... Now that i come to think of it... P.E.O.S? Must be something wrong with following these steps... 🙂
Kind Regards,
Kalimera (Good Morning)
DF
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply