Application Services provides a platform for IT Development and Maintenance professionals to discuss and gain insights into best practices, process innovations and emerging technologies that will shape the future of this profession.

« Agile Adoption - Easier said than done | Main | How enterprises can transition from traditional methods of software development to Agile methodology? »

Simplifying Upgrades: The Analysts' role

Posted by Nitin Sharma, Senior Consultant, FNADT

We love our smart phones and their apps, but we all know how annoying and irritating new updates can be- they change the look and feel of our favorite apps, the buttons we knew are replaced by swipes or gestures, new features we never wanted are added, and those we loved to use are removed or pushed to the background. No doubt, both mobile OS and App developers highlight the bouquet of new features available and how these will make our lives easier but still, everyone would have felt the urge to uninstall the latest updates and keep using the older versions. For me, Google Talk being replaced by Hangouts is one that I am still coming to terms with.
Our apprehensions are justified, even though, the updates are done with our permission, we have accepted the terms and conditions, given the required access privileges, enabled automatic updates or installed them manually. On top of it all, we still have the option to uninstall the updates or worse, the application itself, as there are ten other applications which we can install and check if they fit the bill. And all this is for free.

Now consider an ERP upgrade and the level of angst it causes to the users, who have been using the older version since they remember working, because they know how it works, where it breaks and how to fix it when that happens. They are so comfortable using it that they don't want to change and don't really care about the new features or the easier life the new version promises to offer. Users' concerns over such upgrades are essentially supposed to be recognized and accounted for in the change management and user training strategies currently practiced by most organizations and system integrator involved in such large scale upgrade projects.

The angst of upgrades is not only limited to the clients, but also engulfs the analysts and consultants trying to deliver such upgrade projects. The challenges faced by the analysts are often not considered or given the due emphasis which they deserve. Here are a few key points which should be taken care of by all analysts to simplify upgrade projects and enable smoother upgrades.

The decision makers come along with the wise foxes:
In any project whether a full blooded implementation or upgrades, there is always a particular set of users who are the decision makers, who have the authority to say yes or no and play a very important role in moving things forward. Analysts need to identify these people and build a rapport, so as to facilitate getting the required approvals and sign offs.

And then there is another set of users, whom I shall call 'the wise foxes'. They are the ones who know the older systems/version inside out. They most likely were involved in the implementation of this old version say 10 years ago and ever since have been using, managing or playing around with the version you intend to upgrade. These people are the ones who are to be managed with ultra-care, as they can make the upgrade journey either a fairy tale or a nightmare.

Setting the correct expectations:
Consider this, your project might be to replace the old land line with a smart phone, but some users might think they are getting a satellite phone whereas others might think they are only getting a wireless phone. For any upgrade project to be successful, it is imperative that the decision makers are brought to the same platform and that they understand what they will get as well as what they will not. Once the expectations are inline, it will be much easier to rationalize and prioritize the requirements and decide which ones to Drop, Defer or Do.

Drilling out the requirements:
Requirement gathering is always tricky, but it's even more so for upgrade projects and the prime reason for this is the assumption that whatever was handled in the older version should be handled in the new one too. This assumption being taken as the premise or the starting point for elicitation causes many requirements to be missed, and then leads to scope spillages and timelines not being met at later stages.
Another culprit is the bolt on solutions being used by the organization. Most users will be unable to differentiate between the base functionality of the older version and the customization they have been using over the years. Here, the wise foxes can be very helpful in identifying such customization. Once identified, these need to be accounted for while eliciting requirements.

Being the expert:
As there are two product versions involved in upgrade projects, most analysts need to work with people who know the older version of the product better than they do. Although it will be great to learn and be the expert of both the old and new version, it is normally impractical, as the analyst might not have ever worked on the older version, with no training and very limited prospects on working on the same older version again. Striking a balance and being smart in what you learn about the old version and, more importantly, being aware of the delta between the two versions is the key to help you be the expert the customer wants you to be.

Choice to follow the routine:
Another hindrance in delivering value in an upgrade project is the users' reluctance to use the new, more efficient features. It is difficult to get an agreement to change to a new process, when the old process can still be followed in the newer version, given that the users are used to the older process and are happy to continue using it. In our old land line to smartphone upgrade project, this is akin to users' asking the analyst to configure the new smartphone to enable them only to call, not install any new applications, and they will still use the telephone directory and keep a manual log of calls made.

Minimizing collateral damage:
The integration capabilities of the new version are stretched only to integrate it with multiple old peripheral systems which were used along with the older version. These peripheral systems accompanying the old version require due diligence to ensure that those performing tasks which are still not supported in the newer version are seamlessly integrated with minimum impact on system performance, and those which are not required anymore, due to new versions enhanced functionalities are made to hang up their boots. Peripheral systems can limit the processing capabilities of your new version and act as bottlenecks. Analysts need to tackle such problems by demonstrating how the existing processes can be handled in the new version and restrict unnecessary peripheral systems to the minimum.

All such aspects of ERP upgrades makes them a very intriguing journey, which leaves behind a plethora of lessons learnt, and more significantly, footprints that remain ingrained in the analysts' minds to be revisited during many such voyages yet to come.


Well written article and much applicable for our roles. Yes it is difficult for the analyst when an upgrade is happening from all sides and we need to act smart to tackle the issue as it cannot be avoided in full.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.