THE ART OF A SUCCESSFUL ANALYTICS UPGRADE PROCESS
Lindsey O’ Grady – Practice Lead Planning & Analytics
I’ve recently completed a successful Cognos Analytics and Planning Analytics upgrade (PA 11.0.6 and CA 11.1.1). It has now been signed off and I was able to give my customer a guided tour of all the new tools… out the with the old, in with the new! My customer is now the envy of many – a smooth upgrade, reasonable timescales, and eagerly discussing how it will completely change the way they work. So how was it done and what are my best tips?
Tip 1: How to make a project plan
An upgrade can go very smoothly provided all parties know what the road ahead looks like. Here’s a simple Gantt chart of a typical upgrade process. From your plan, agree the dates with those assigned to each task. Nominate someone to be responsible for making sure everything starts and finishes on time, or can rework the dates if they don’t.
Tip 2: How to test
There are many steps to the technical build, and each solution and software version is very different. Never assume the new software will “just work” because you’ve followed the instructions.
There are two types of testing
1) does the software work (i.e. functional testing), and
2) does the solution within the software work (i.e. user acceptance testing).
Functional Testing
There’s nothing more frustrating for a user during their first attempt at UAT when they can’t log in, all reports error, and basic functionality like exporting to a PDF or emailing doesn’t work either. Before handing over for UAT, some basic tests of functionality of the software must be carried out. Functional testing can be carried out by the person installing the software and tested by someone who develops solutions in the software.
Example functional tests for Cognos Analytics: Can I log into the web portal? Have images been copied over? Have all the users and groups been set up correctly? Is the security compliant with licencing? Do all the samples work? Have the Framework Manager models been copied over? Do the reports run ok? Can I run a report to PDF? Do all the distribution methods work correctly (file system, email)? Do scheduled reports execute successfully? Are all the schedules turned off so that they don’t send out reports from the new system as well as old (that old chestnut!)
Example functional tests for Planning Analytics: Can I log into the web portals? Can I log into the Excel tools? Do the file paths for data sources match the same path as before? Do I need to update TI process file paths if they aren’t? Have ODBC connections been set up? Are there any browser compatibility settings required? Have relevant Chores been turned off that might affect a live system? Has security been set up the same as before? Do security rules need updating if they are changing security methods?
Write a checklist of tests and mark each one with Pass or Fail. Installer and application developer should work together using their strengths to get the software settings right. I allow up to 3 rounds of rework in the plan, just in case. I keep adding to my checklist with any new learnings from the previous upgrade.
User Acceptance Testing
UAT can be carried out by a selection of people who represent those who use the solution. I often find that users are never really sure how to “test” things. There’s a risk there that they don’t perform adequate tests and you go live with a solution that needs a lot of go live support!
Arrange a handover meeting with the users beforehand, agreeing what is going to be tested. The installer and application developer can use their strengths to make suggestions on what is a good set of tests. Sometimes the user interface looks very different so use this session to train them on the new interface. I often end the session with a revised list of what’s to be tested to help them out and keep track of progress.
Users should keep an issues log and kept up to date with what’s been fixed.
Tip 3: How to go live
The new environment will contain data from the current environment at a point in time. By the end of UAT, the data will be out of date so Go Live will involve re-migrating the latest data across one last time. Beyond this point, no one should be using the old system anymore. The new software will be available after the copy is complete and basic tests have been performed by a nominated user, confirming sign off of the new upgrade at that point. This often means that the go live process needs to be a quick and seamless to minimise downtime. Decide a cut-off point and communicate downtime to the users.
After the cut-off point, everyone will need to use the new tools, so think about deployment of the new software. Web portals should be easy to deploy – replace intranet sites with new links, or email the new link. Remote app software is easy to update too as you only need to update the install in one place. However…. local machine installs are more time consuming and need some planning to ensure each user’s machine is updated. You could do this in advance of the go live date, provided they don’t clash with the old software on the same machine.
It’s useful to plan for relevant people to be on hand that day just in case something was overlooked and there’s an urgent fix required. Have the project team on standby. At a suitable time when the new upgrade is settled, IT can retire the old environment.
Summary
So there’s my best tips on what a successful upgrade looks like. There are many benefits to staying up to date: you stay on a supported version, you benefit from new features which save time/effort, and gives you new insights and capabilities that you never had before. I’m happy to help anyone who needs to upgrade so please get in touch if you’d like to know more!