Unintended Consequences: When Software Installations Go Off The Track
April 2, 2018 Dan Burger
It’s not like we never hear about the positive benefits of software upgrades or new software installations. There is no shortage of case studies that tell those stories. But the unintended consequences that gut punch implementations get a fair share of attention wherever IT professionals gather. These are usually complex and expensive projects where anything that goes wrong is magnified, but wounded projects know no boundaries. Workflow barriers, surprising conflicts, and disappearing functionality curse projects of all descriptions.
Do you have an implementation specialist on staff or a trusted consultant to lead you to software implementation victory, or do you rely on the software vendor to not only manage the installation, but also avoid integration headaches? To answer that question, you need to make an honest assessment of your staff and your vendor. Someone has to be able to anticipate, avoid, and address problems that can occur before, during, and after an installation.
“If you don’t have time to do the analysis work before the install, you shouldn’t be doing it,” advises David Contreras, a consultant specializing in system integration and modernization. “You better hire the work to be done.”
IT Jungle talked with Contreras earlier this year for an article titled Overdue Upgrades Perplex IBM i Shops. In a follow-up conversation last week, he and I spent more time discussing how to get the expected result from a software installation and the difference between a functional success and an operational success.
Because the application is functional – it does what’s expected – doesn’t mean that it’s operational and plays well with the rest of the IT environment. Who’s responsible when new software or an upgrade of existing software raises hell with disparate applications?
“A bad outcome is usually the result of the shop not doing the homework – not knowing what they have, what needs to be done, how it’s going to get done – or understanding the potential ramifications on other areas of the business,” Contreras says. “It’s not the software vendor’s upgrade that is likely to burn you. It’s going to be everything that surrounds it – the integration points.”
The responsibility is not on the vendor unless that is spelled out prior to the installation and that will require a services fee in addition to the software license and any training that is part of the package, Contreras says. An analysis of programs that touch the new software is mandatory before the installation begins. The analysis can be negotiated with the vendor in some cases, but it often is the responsibility of the organization buying the software. In some environments there can be dozens of custom interface programs, or hundreds or thousands. With no knowledge of this, a software install can cause programs to start blowing up in all sorts of surprising places.
Simple cross-referencing queries can prevent a high percentage of these explosions by identifying integration points that will be troublesome if ignored. The commands can cross-reference programs and cross-reference the database.
“The commands send queries to every file that’s associated with a specified program. They provide program names and libraries and identify the low-hanging fruit,” Contreras says. Someone needs to examine those programs and figure out what’s intertwined with the program you are upgrading or changing. The queries help identify custom code – maybe to the extent that you realize the upgrade will take longer than first determined.”
Regardless of a smooth installation and staff training on the care and feeding of the new software, disruptions probably will occur if the cross-referencing step is excluded.
Organizations need to have a conversation with the vendor about the preparations prior to the install that increase the chances of meeting functional and operational expectations. If the vendor is not part of the analysis process, the organization buying the software should still request a level of cooperation and insights based on the vendor’s previous installation experiences. They should provide a summary of what needs to be done prior to the installation, regardless of who is doing the work. Depending on how much a company relies on the vendor for advice, there may be services fees involved.
Vendor advice could certainly include potential integration weaknesses, but that stops short of being responsible for a program that someone else wrote.
“If a vendor starts touching stuff that’s beyond the installation of its own software, it could be opening itself to liability,” Contreras says.
At the very least, ask the vendor to provide a list of things to watch out for based on all the installations they’ve completed.
Use the pending software purchase as leverage to gain cooperation that will make the installation a smooth operation. Remind the vendor that a satisfied customer provides software and maintenance revenue that is not currently on the books. Move forward, get the job done right and everyone is happy.
Keep in mind, if you are relying on internal staff to do the preparation work and the installation, you must have confidence in their knowledge and be comfortable with the time they have available to devote to this project. Your option is to pay to get the knowledgeable assistance, whether it’s the vendor’s services or an independent consultant of your choosing who can project manage the job for you.
“Get everything on paper about the expectations for the software and the assistance in preparing for the install to be both functional and operational,” Contreras advises. Contingent upon that, let the vendor know your company will sign an agreement with the agreed upon dollar amount specified.”
RELATED STORIES
Overdue Upgrades Perplex IBM i Shops
IBM i Trading Punches In The Automotive Supply Chain
With RPG Nearly Excised, Infor Ponders ERP’s Future
The Negative Impact Of Software Pricing On The IBM i Community
