info@meradia.com
WHERE TO BEGIN: PROTECTING AN ORGANIZATION’S INVESTMENT
Investment management organizations dedicate significant resources to evaluate systems’ functionality, cost, history and data to safely align with their requirements; and to make the final system selection(s). Once an organization has signed the vendor contracts, they must remain diligent throughout the conversion process.
When it is time to implement the new system – whether it is a complete suite of software products or just one component – the steps to mitigate risks are common across conversions and should not be taken lightly. Data indicates that over 70% of implementation projects fail or run over budget and/or time planned for the implementation.
By simply being aware of the common risks associated with implementation projects, an organization will be in a stronger position to avoid them; therefore, increasing the success of the implementation – and protecting the investment made to date.
1 The 2015 Chaos Report, Standish Group
2 PMI’s Pulse of Profession, 2017
MANAGING RISK FACTORS BEFORE SYSTEM IMPLEMENTATION
Thoroughly manage the following items to prevent them from becoming risk factors to system implementations.
Obtain Buy In From Required Levels within the Organization
Failing to get buy in from stakeholders is a more critical risk than the lack of a solid project plan, and it can undermine even the strongest of project plans.
A system conversion presents a significant change for everyone in the organization, especially for those who use the system daily. They are often the hardest ones from whom to get buy in. They are familiar with the current system and in many cases do not see the bigger picture or the benefits of change. It is vital they fully understand the need for the change and to engage them as stakeholders in the project. Clearly articulate the reasons for the change, the benefits the changes it will bring to the organization and to staff members alike. This can be a challenge, although if it is approached astutely it can be successful.
Strategies to keep stakeholders engaged after obtaining buy-in include:
- Conduct periodic training sessions, (training will be addressed subsequently).
- Celebrate milestones as they are met.
- Recognize the hard work of the staff often to boost morale. When done effectively, it creates project visibility.
- Identify and establish subject matter experts and super users during the project. Ideally one or two resources will stand out as having a strong grasp of various key components of the new system. Request they share their knowledge and leverage their skills to ensure successful implementation.
- Solicit feedback from users frequently. Asking them for their opinions reinforces to them that they are key stakeholders.
- Conduct demos as functionality and or data becomes available. This will allow users and other stakeholders to see the benefits and added value throughout the project.
Formulate a Strong Project Plan
Whether deploying Waterfall, Agile or some form of Lean Project Management, the key is to have a strong project plan and methodology and to stick with it. A strong plan extends beyond securing a budget and setting an end date. It also includes identifying stakeholders, product owners and other members of project teams – and then obtaining buy in from each of them. The plan must provide for consistent communication to stakeholders to ensure they feel like a valuable part of the team and to eliminate surprises.
Ensure a Productive Working Relationship Between Client and Vendor
The honeymoon is over – the contract is signed. It is likely the vendor representatives who originally conducted the demo and sold the system have a small, if any, role in the actual implementation and conversion. There is now a new vendor team working with an organization’s staff to convert to their system.
Although both the vendor and the client have the same goal to be successful, often the client turns against the vendor because something does not work the way they thought it would. Just as often the vendor turns on the client because they do not understand their system and how it functions. The key to success is to remember the client is the expert on their business and the vendor is the expert on their software. Forgetting this can yield a project risk. Working together to ensure the vendor understands the client’s needs and the client understands the vendor’s product functionality is a strong tool to mitigate this risk.
Plan for Proper and Ongoing Training
Training is critical, yet often gets put on the back burner. Afterall, the resources who will be using the new system are simultaneously performing their responsibilities on the legacy system, helping with the conversion and need to learn the new software. Following are some of the methods to effectively accomplish this.
- Determine what training is available from the vendor and if there are training hours built into the vendor contract for new clients. Take advantage of this as early as possible.
- Train the trainers. Identify one or two key individuals to take part in formal training so they can continually share that knowledge with the remaining staff.
- Make time for knowledge sharing by scheduling meetings throughout the week to cover training on functionality that will be key during the upcoming implementation weeks.
- Share tips and tricks via the preferred channel, such as by email or using collaborative workspaces such as Teams or Confluence, which is the current trend.
- Encourage staff members to share knowledge with others as they become more familiar with the product.
Proper training will help the project go smoothly and mitigate the risk of having a poor relationship with the vendor. Poorly trained resources are one of the primary causes of unhappy clients and unpleasant client/vendor relationships.
Use Case:
When a vendor requested that a consultant visit a client who voiced dissatisfaction with the vendor software’s ability to perform required functionality, the consultant determined within an hour of arriving onsite that the client’s disappointment with the system was due to their lack of functional knowledge. Once the consultant bridged the knowledge gap, the client was so pleased with the product they became a satisfied and referenceable client.
Ensure Data Integrity
Don’t underestimate the effort required to ensure data is accurate and fits into the new system. It is likely that no matter the type of system implementation, there is data to migrate from the old system to the new system. It could be as simple as migrating accounts to a new trading platform, or as complex as migrating everything to a new data management solution. The following are a few key questions to consider when migrating data.
- Is the data accurate? The phrase ‘garbage in, garbage out’ applies here. Migrating incorrect data into a new system will give the appearance the new system does not work properly. Take the time to identify and correct data prior to migrating it to the new system.
- Is the data in the old system compatible with the new system’s structure? This goes hand-in-hand with data accuracy. When replacing a system with a new and better product, there are often additional data quality checks and improved flexibility. The differences between an old and new systems could cause the data migration to fail. For example, the old system may have stored data as simple string fields which could have allowed for alpha characters in fields that should be numeric; or may have allowed for certain types of fields that require limits, such as US state codes, to have extra characters. The new system will likely have specific field types to accommodate the data and to prevent loading or entering incorrect data.
- Is data transformation and mapping part of the plan? In addition to data being accurate and compatible with the new system’s structure, it is likely the new system allows for greater flexibility and granularity which introduces a level of complexity. Also, certain key fields may contain system code values. For example, when converting a trading system, the old and new trading systems may define specific code values for transaction types differently. The old system may have simply specified B = any type of purchase and S = any type of sell. The new system may have more specific code values such as BUY = regular purchases, COVER = covering a short sale, SELL = regular sell, and SHORT = short sales. It is critical to identify data transformation and mapping considerations before beginning data migration. There will likely be scenarios that require specific transformation logic to map data correctly.
Conduct Comprehensive System Testing
Organizations often ignore system testing until near the end of the project. Regardless of the project management approach, consider a testing strategy before implementing the first component. Agile project management does a good job at preventing this from happening by early and continuous delivery of valuable software.
Each requirement upon which system selections are based should be included in the test plan. Equally important is defining the acceptance criteria. Each phase, release and milestone of the system implementation project should have its own testing component and defined acceptance criteria. In some cases, a component can be implemented if there are minor issues identified in the prior one. In other circumstances, issues need to be remedied before moving forward. The criteria for progressing through the phases of the implementation should be well defined in the test plan.
Successful testing of all functionality depends on the testing environments and data completeness of the environments. Environments that allow for sufficient unit testing through to user acceptance testing best support successful testing. Testing available recent data and data that represents all system scenarios is critical. For example, an organization may trade derivatives infrequently. It is important to ensure the test environment includes examples of these trades to ensure the functionality works properly. In some cases, it is necessary to either go back into historic data or create test data to thoroughly test certain scenarios. Do not limit testing to data that is readily available.
Finally, avoid assuming that if the new system performs exactly what the old system did, then testing is successful. If testing accounts for only the functionality performed by the old system, then implementing a new system would not have been necessary. New functionality performed by the new system needs its own relevant testing parameters.
HOW MERADIA CAN HELP
Meradia has decades of experience managing small to large-scale implementation projects, and substantial experience with the leading financial services software providers currently on the market. Meradia consultants can help investment management organizations avoid common risks and ensure a successful implementation by leveraging proven methodology for system conversion projects.
Download Thought Leadership Article Conversion and Implementation All Meradia Asset Managers Meradia Consultant