AltaReturn on how to survive a tech implementation

This article is sponsored by AltaReturn.

Q The idea of switching back-office technology providers might be daunting to some. What do you tell them to alleviate their concerns?

The main thing is to have the CFO or whoever’s the driver of putting in the new technology really think about the reasons why they want to do it. Typically, they have a list of pain points or things that they’re struggling with or not able to do efficiently; it’s taking them too long to produce their quarterly reports, for example. Or they can’t get capital call notices out on time. By thinking about what you’re trying to achieve it will really help you move forward. You have to weigh the costs and benefits of staying with the status quo.

Q Is it harder to move from MS Excel or from another vendor’s platform?

It really depends on the other vendor, because if the data’s already stored in tables in a similar database, generally speaking, that’s always easier for us to extract. Typically, GPs that are on Excel have a million versions of the same spreadsheet. It’s very difficult; they don’t tie to each other. It’s very difficult to define the right version of a certain spreadsheet. However, it’s important to remember that at AltaReturn our core fund accounting platform is very much G/L oriented. So if the other vendor isn’t really accounting-based per se and the GP is coming off of a system that really didn’t store the data as debits and credits in an accounting function, it’s a little bit more complex.

Q What’s the biggest challenge you’ve faced in implementing a new back-office suite for a client?

Recently, we had a very good project in terms of migrating the data; it reconciled, everything was great. But when the management originally chose the system, they didn’t involve the users very much. Once we switched the system on and had training, the users really didn’t know what to expect, which led to some confusion. It’s important to have that initial conversation to get everyone on board by saying, ‘Okay we’re changing systems, it’s going to be different. These are the reasons why it’s going to be better.’

If that conversation doesn’t happen with the people that are actually going to be users of the system, then it can be very difficult for us. This led to some resistance when we came in to train people. Eventually we were able to work through that and it came out fine, but there was that initial struggle that we weren’t anticipating because we weren’t aware that people really weren’t told enough about what was going on.

Other challenges we’ve encountered much more recently – complex fund structures. In private equity, there’s a lot of hybrid structures, multiple AIVs and blockers, and there’s all sorts of things going on.

One initial conversation with a GP recently started by them telling us, ‘Oh, it’s just a simple straightforward fund structure,’ and all of a sudden it’s this huge spaghetti and meatballs diagram of entities everywhere and offshore vehicles and things that we just weren’t anticipating. We can obviously handle those types of structures. But when you’re walking in not expecting it, we have to re-scope the project and help the team understand that, ‘Okay, this is going to be a little bit more complicated to implement versus just your standard fund investing into portfolio companies.’

Q What would you say are the key factors in a successful implementation?

First, having the full support of management as well as the end users and the staff. Making sure everybody’s on board but continuing to have that management support so whoever is actually doing the work of the project, they have time to do it, instead of saying, ‘You have to do this off hours.’

Secondly, having a dedicated resource or partially dedicated resource to the project will ensure a more successful implementation, because they’ll have more time to focus on the data migration and reconciliation and making sure that everything is working well.

Lastly, make sure you have a clear understanding of the goals of the project. A lot of times people go into these things and it’s not really clearly defined, ‘What are we trying to get out of it?’ At the end, everybody’s looking around and wondering, ‘Okay, are we finished?’ If we can clearly define from the beginning of the project what are the key factors to consider it makes the whole process smoother.

Q What does the implementation planning process look like for a new client?

We have an implementation methodology that we follow for all of our clients regardless of their size. It can adapt to basically any project size. It starts with the design phase of the project, which is where we’re working with the client to define the requirements and their needs for all of the applications that they’ve licensed. For example, if we’re implementing a fund accounting system and CRM, we would have two separate design sessions for that, document all of the requirements in a specific document that the client must sign off on. That’s basically the roadmap for that implementation.

That’s the first phase of the project. Then we move on to the configuration. We configure the fund accounting and CRM or whatever other applications based on the contents of the design document. Again, that gets reviewed and signed off by the client. Then we move into the data migration phase, which is always the wild card in the project because that can take any amount of time, depending on how long the client takes to get us back the data that we need in the format that we need.

Then we go about writing reports – this includes any of the requested reports and outputs from the project we began to work on once the data has been migrated. Then we have training. There’s separate training sessions for the different applications. That’s both onsite and offsite, so we’ll typically go on site for that initial training, but training goes on until people are comfortable. We’ll schedule weekly sessions, ask questions and do follow-ups.

Then basically after training is when we can consider that client in user acceptance testing. We work with them through their UAT to resolve any issues. Then, from that point forward, we issue them what we call a production release notice and then consider that particular client in production. That doesn’t mean we’re not going to work with them anymore. It’s just that project is considered done.

Q In a recent survey 66 percent of CFOs said their fund structures are becoming more complex. How can technology help?

Technology plays a big role in actually creating efficiencies around these complex fund structures. Depending on the technology you choose, you might get a different type of efficiency. But where AltaReturn is concerned, it is around getting people to do less work through the use of technology, even in a very complex structure: still being able to input a transaction, for example, a single time and having that transaction flow through the structure without having to re-input it in every single place where it might have a cashflow impact. That might not sound like much, but when you start adding up all these little improvements, there can be significant efficiencies made overall.

Q If there was one thing you would tell a GP that is hesitating from moving off its current system, what would it be?

One thing I would say to a GP is that if you continue to use antiquated technology or no technology at all, your LPs will notice. A lot of our potential GP clients say, ‘My LPs have logged into one of your portals and they liked it so much, they wondered why we’re not using AltaReturn?’