Business users often act as if upgrading their investment system is like getting a new version of Microsoft Excel. It’s not. When Excel updates, nobody writes a project plan.

Nobody runs regression or unit acceptance testing across it. Nobody checks that every one of the hundreds or thousands of features the business depends on every day still behaves the way it did last quarter, or proves that the reports still tie out before anyone is allowed to open it. The new version simply arrives, and if something looks different you work around it. An investment accounting system cannot be treated that way, and the difference is not one of degree — an upgrade there puts portfolios worth billions of dollars in play. It probably needs to be upgraded annually, for regulatory or other business reasons; and it needs to work, usually in a short timeframe, without breaking anything else.

Most companies have limited numbers of IT and business people, with other jobs to do, and with limited experience in systems upgrades, testing, and project management. It’s unreasonable to expect them to take on the upgrades of their investment systems. In fact, it’s arguably unfair.

It may not be any more reasonable or fair to expect vendors to deliver new versions of their investment systems with no software glitches. Vendors certainly know their systems. But they don’t know each client’s environment. And companies need to run the systems, in their environments, using their processes and workflows to see if their requirements have been met and to ensure a coding change here hasn’t created a problem there. And the vendor’s timeframes might not be yours. Third- and fourth-quarter crunches for year-end reporting requirements don’t leave much margin for error, let alone on-the-job training.

What to do?

  • Define: Identify and document your requirements for the new version, including present states and future states to take advantage of new functionality. That will enable you to grow into the new version.
  • Dedicate: Build a team that comprises business and technological knowledge, and make sure the members can devote a substantial amount of their time (80 to 100 percent) to the upgrade.
  • Deputize: Give the team authority to cross organizational boundaries to overcome business and technical roadblocks, bottlenecks, and resistance.
  • Mimic: Use test cases for regression testing that duplicate the company’s key day-to-day operations. Then, you’ll have confidence that the system still accommodates the basics as you test out the new functionality.
  • Consider: Take into account all the people in the company who will use or receive output from the new system. These might include people in investment management, investment accounting, trading and settlement, and other departments. And make sure everyone can see the upgrade in action during testing.
  • Report: Let your vendor know the functional problems you encounter — or the enhancements you’d like to see — so they can be addressed in the next release.

You want to see what you have in the new version. You want to know what to expect from it, and you don’t want anything that works in or with the old version to break. It’s simple to say, but veterans of the process know it’s not simple to do.