Guiding Principles for Digital Transformation of Investment Systems
Digital transformation within the capital markets is typically a multi-year journey that requires tenacity, commitment, and agility from all stakeholders. At their core, most investment management transformation projects include the implementation of one or more applications that will replace the legacy systems and processes, which may have been used within the organization for years.
If your capital markets organization is going to implement—or is in the process of implementing—a large-scale digital transformation project, we recommend the following seven guiding principles to help your project achieve a better result.
Principle 1 – Identify the business objectives holistically
Although it might seem intuitive at first, this principle is the most likely to fail, and it has the largest consequences to the organization. To understand why, we just have to look at human nature and the competing priorities of the various stakeholders:
- Software vendors want to sell software and licenses. If the organization wants a business-function-specific solution and budgets to implement only that, that is what they will offer, pitch and sell their clients.
- Consultancies and implementation partners want to sell services. Similar to vendors, if the client wants a one-year project, they will pitch a project that fits into a one-year timeline.
- Company executives and internal stakeholders all have their own objectives and competing priorities. Some might want to expand their operational scope and responsibilities; others might want to cut costs or transform to a more digital operating model.
Whatever the various stakeholders’ motivations, it is important that organizations fully understand their business objectives and whether those objectives make sense holistically within the context of the current organizational structure and existing capabilities.
Failure to holistically consider transformation goals within the context of the capabilities and state of the organization will lead to costly re-design or re-architecture at later stages.
In a real-world example of this principle, a mid-sized asset manager wanted to replace the company’s Investment Book of Record (IBOR) system. This system performed functions like pricing and valuations, performance, portfolio management/view, and other typical IBOR functions. The vendor sold them an “IBOR-only“ solution and promised a simple and short implementation, with other key-functionality like Accounting (ABOR) to come during subsequent project phases after the initial implementation. After the design phase, when planning for the integration and User Acceptance Testing (UAT) was starting to kick off, the Operations and Accounting teams became more involved, and the inevitable questions came:
- “How and when do we implement the ABOR solution?”
- “If the ABOR is coming at a later phase, how do we generate the accounting entries required to satisfy our current financial reporting?”
- “How do we add on the ABOR component and bring it up to date? Do we have to do a re-conversion exercise? How do we generate all the back-dated GL entries?”
What resulted was a costly re-design process. A temporary accounting solution had to be built within the “IBOR-only” solution, which ended up delaying the project for months and incurred significant financial costs. This seemingly obvious missing piece was not included as part of any RFP/vendor proposal. It was absent from initial requirements, and when it was finally brought to the surface, most stakeholders feigned ignorance and claimed “out of scope.” When executive management became involved, they threatened to cancel the project as it was not compatible with current BAU operations. Although it might seem extreme, this type of scenario is very common, and most large digital transformation projects go through a re-design or re-scoping process.
To lower the risk of this happening, we recommend the following:
- Have a clear understanding of the Target Operating Model (TOM) and how each system fits into both the current and target ecosystem.
- Define a high-level project plan/charter, which should reference the TOM. If the project plan has multiple phases, it should consider how each phase will impact the current ecosystem and processes.
- Involve ALL internal stakeholders up front during the planning and vendor selection phases. Silo-based pet projects often lead to difficult integration during later phases.
By having a clear understanding of your TOM and business objectives, your organization will have a more focused and pragmatic project within the context of the current and future organization ecosystem.
Principle 2 – Create an effective project governance structure.
Creating an effective governance structure is critical to any large digital transformation project. Without an effective project governance structure, it is likely the following will happen:
- No clear ownership and lack of accountability; meetings are unproductive and do not focus on solving issues.
- Duplicate work and wasted effort on low priority/severity tasks.
- Inability to track accurate project status and completion percentage of major milestones.
- Cost overruns, inefficient resource management, and constantly shifting dates.
- Large amounts of re-design and re-architecture of key functions.
Unfortunately, most of the above is apparent only after the project has already started—at which time, making changes to governance is more difficult than it would have been at project initiation. As a best practice, we encourage defining the governance structure up front. We suggest the following:
- A clear reporting structure and meeting cadence with escalation points:
- Executive / steering committee: The executive committee should be the final escalation point. It aims to make high-level decisions regarding timeline, budget, and other mission-critical matters. Members should include C-Level executives, vendor leads, and implementation partners leads.
- Project lead working group: The project lead working group should be the second highest escalation point. It should involve all three champions for the pillars below, workstream leads, and vendors/consulting partners. In addition to being an escalation point, this forum should be where workstreams formally request extensions to move dates or request additional resources.
- Business, data, and technology champions: Most projects involve business, data, and technology. This working group should be the last escalation level for each of the three pillars. It aims to resolve working-level issues and provide guidance to the work streams within the pillars.
- Workstream: The lower level working groups. These are the individual project working groups, usually having multiple groups within each of the three pillars above. Typically, these are defined at the functionality or domain level.
- Clearly define the standards and methodologies to be used across all workstreams. This helps to ensure that all workstreams are speaking a common language and are using the same data points when creating management reporting/tracking (see Guiding Principal 3). Some examples of this include priorities definition, severities definition, reporting metrics/data points, business requirements, user story templates, test case templates, linkage standards, project plan standards, and management reporting templates.
- Clearly define the technology and tools to be used within the project. This should define the how for the project and provide a common delivery framework to be used across all workstreams.
Although each project and organization is unique, the above guidelines can be used to begin the governance conversation, which can be further tailored to each individual project and organizational working style.
Principle 3 – Make data-driven decisions
The benefits of making data-driven decisions should be clear to any seasoned executive. Reliable data-driven decisions allows unbiased and statistically significant decision-making, which is more actionable than intuitive decision-making. Within the context of digital transformation projects, this data (e.g., reporting metrics, RAG, % complete, etc.) is usually generated by the various workstreams and presented to project leadership as part of various stakeholder meeting updates. The challenge to making data-driven decisions is how to gather the right data and metrics as input into the decision-making process.
Everyone wants to do the model work, not the data work
We recommend the following guidelines to generate highly accurate, relevant, and timely data to be used in project decision-making:
- Clearly define standardizations as to what constitutes a unit of work across the different project phases. This is typically needed for: configuration units, test cases, and project artifacts (e.g., documentation, process/data/requirements, etc.). This is to ensure an apples-to-apples comparison across the various project stakeholders that can be rolled out to a summary level view.
- Use project management software to track execution results and to create public reporting dashboards/views for all workstreams. All meetings, updates and reporting should be based on these dashboards and should be updated by individual contributors and leads frequently. Avoid using Excel sheets.
- Quantitatively build rules around Red, Amber, Green (RAG) status reporting and other metrics. Any deviation can be explained through qualitative reasoning, but the status itself should follow binary logic.
- When there is not a standardized way to report workstream status—or even worse, to use excessive intuitive or judgement in the reporting process—it is likely that the actual project status is not aligned to what is being communicated to executive stakeholders.
This misalignment of reporting metrics and delivery results can happen when project reporting standards are qualitative (emotion-driven), not quantitative (data-driven).
If this variance between actual vs. reported status updates persists, usually it is discovered too late in execution of the project/phase, at which point, the only course of action is to either reduce scope or shift dates. Avoid falling into this trap by clearly defining what tools and metrics are to be used by the project and enforce all project stakeholders gather relevant data points for reporting. When clean, accurate, and reliable data is available to project stakeholders and executives, everyone can make better decisions.
Principle 4 – Assemble a diverse team
A digital transformation project requires a team of professionals with a variety of skills and expertise spanning several domains and subject matter areas. It is important to choose team members who are committed to the project and have the necessary skills and experience to ensure its success.
Although each project—and organization—is unique, we recommend the following when building a strong project team:
- Focus on creating a collaborative project culture. With any large project, there will always be politics, silos, and other obstacles to implementation. By nature, humans do not like change, and digital transformation’s goals are to change existing processes and systems that users have become accustomed with. Creating a collaborative, respectful, and accountable project culture is critical for any digital transformation project to succeed.
- Engage users and subject-matter experts up front. The current system users need to be engaged from the start, ideally when they are formally participating in working group sessions and making Target Operating Model (TOM) decisions. By waiting for the tail end of the project to involve users (e.g., during user acceptance testing), there is a high risk that implemented functionality will not meet expectations which will lead to re-design and/or de-scoping functionality.
- Create a diverse and well-rounded team. Capital markets is an industry that is constantly evolving; no one is able to act as a subject matter expert across all domains, technologies, and systems. We recommend creating diverse project teams that should include the following members:
- User subject-matter experts: These resources are needed to provide expert-level guidance, requirements, and validation for target-state decisions and processes. They typically come from within the implementing organization and have a senior role; they understand the current state and have a vision as to what the target state looks like.
- Vendor configuration experts: System specialists, usually employees from the software vendor(s). These are expert users and are the basis for any design and configuration of the target system(s).
- Implementation specialists: These are typically consultants and have significant experience with system implementation. They are typically responsible for key deliverables including requirements, testing, project planning/strategy, and other areas such as data conversion.
The table below summarizes a typical project staffing model, and how to best utilize project resources.
Principle 5 – Focus on the Target State, not the Current State
The priority and vision of any large transformation project should be to focus on the target state. One of the most common mistakes is that instead of creating new processes and solutions based on target systems/architecture, the project focuses on replicating legacy functionality.
For example, reporting is often a substantial effort within any digital transformation project. After years or decades of service, there might be hundreds or even thousands of reports that are used for subsequent business processes or analytical activity within the organization. One common mistake is instead of looking at reporting with a new lens, the organization focuses on re-creating the exact same extracts in the target system that the legacy system used to generate.
This approach will inevitably fail for the following reasons:
- The system architecture and calculation methodology of different systems cannot be compared, especially when working with the complex mathematical equations typically used within the capital markets.
- The data design of two systems is different. They do not have the same database structure or the same data elements, and usually, both lack adequate meta-data to do proper comparison.
- The amount of effort involved to analyze each and every single legacy report and to re-build those same reports is not achievable without significant economic costs.
For this example, a pragmatic approach is to bucket each report as follows:
- Identify all the reports that cannot be changed (e.g., regulatory reports). For this category, the reports must go through a replication process.
- Identify which reports are used systematically (e.g., reports that are used for systematic processing or sent through interfaces). These reports can be analyzed on a case-by-case basis, as they can potentially be re-engineered based on the target state functionality.
- For all other reports (e.g., reports used by users, for management reporting, etc.), the project should focus on explaining target system reporting capabilities and using a self service model.
Based on the above, the project team should focus their efforts on understanding and building target-system functionality. In most cases, the target system will have more available features and opportunities to automate and improve business processes.
Digital transformation requires a clear vision and understanding of target-state capabilities. Without this, you are buying a brand-new Ferrari and jamming your old Toyota engine into it.
The two best ways to focus your digital transformation efforts on improving and not replicating are as follows:
- Involve subject-matter experts, vendor specialists, and implementation specialists when defining requirements, user stories, and design. A more diverse and knowledgeable review and approval panel typically creates a more robust and pragmatic solution that better meets user needs.
- Understand the target operating model and target software architecture and its capabilities. By thoroughly understanding the software and target architecture, the project team can proactively identify improvements in the target state. This process can also help to flag any gaps or required enhancements (e.g., regulatory requirements) up front, which will save time during subsequent project phases.
All digital transformation projects go through challenges related to integrating legacy processes. By having a project culture that has an open mindset with a focus on the target state, the end-result is often a huge improvement when compared to the old way of doing things.
Principle 6 – Don’t forget about data conversion
Data conversion is, in a nutshell, moving data from your legacy system to your target system. Depending on the target system, it typically involves moving positions, transactions, reference/static data, and other data elements. This process usually entails creating custom extract-transform-load processes with a lot of databases and scripting. In addition, there is typically a lengthy accounting and position reconciliation process, to ensure the target state is aligned with the legacy state.
One of the most challenging aspects of data conversion is that it is the only workstream that can prevent even a well-functioning system from going live. As the starting point of the new world relies on highly accurate data from the old world, having a successful and well-planned data conversion is critical for any large digital transformation to be successful.
Data migration should be integrated as much as possible into the other project phases and not seen as a silo activity.
Data conversion should be seen as a resource that can be utilized from the start of the project, not a silo activity that comes only at the end. By using conversion data throughout the project, you are improving the testing and quality of the data conversion by using real-world production data and validating the process by using it in other testing efforts. Data conversion typically has its own challenges, and it is unlikely you will be able to do full portfolio conversions ad-hoc during earlier project phases (i.e. Functional or SIT). As such, we recommend using a model portfolio approach, where a subset of portfolios are converted at a regular interval.
By providing converted data from legacy system to target system at regular intervals throughout the project, the following benefits can be realized:
- You can validate data and compare to production results. This is especially helpful for testing components such as NAV or quarter- or year-end processes which are cornerstones to any financial reporting.
- Loading conversion data from production into your test environment allows testing workstreams to validate processes using real-world use cases, not fictitious ones.
- Production data in your testing environment will improve test quality and testing efficiency. As a simple example, by loading positional and transactional data into your test environment, testing workstreams can leverage high-quality data to perform subsequent testing (i.e. corporate actions) without having to build a position.
- Doing regular data conversion test loads helps to refine the data conversion process. In addition, testing on this converted data helps to pre-emptively flag data conversion issues.
As a guiding principle, we recommend integrating the data conversion efforts as much as possible into the other project workstreams and phases. This is a win-win situation for all project stakeholders and often leads to a better project outcome.
Principle 7 – Have a comprehensive test strategy
Testing and validation of the target system software is required for the implementing organization to be comfortable with turning off their legacy system and turning on their new target system.
At a high level, we recommend the following as part of any test strategy:
- Enforce that ALL test cases are linked to either approved design or requirements/user stories. Doing this reassures management that all configuration elements have been tested, and it enforces that testers are validating applicable functionality.
- Have clearly defined testing phases, where results are reviewed by subject-matter experts and other stakeholders after each phase. We recommend defining unit, functional/system, integration, end-to-end, and user acceptance test phases in a standard waterfall project.
- Define what constitutes a test step/test case, and clearly define testing priorities, severities, complexities. (See guiding principle 3 above)
- Define a standard testing template (or better yet, make this template in your testing/project management software) and enforce its use across all workstreams. Each test case should be thorough and test multiple functional elements or an entire business process. Avoid creating too many or irrelevant test cases.
- Use testing software for tracking and reporting. This enables project management and leadership to have a clear view of progress and execution time remaining.
In addition to the above, we also encourage you to start to evaluate and consider automated testing as early as possible. By evaluating and understanding how to setup a good automated test framework, even if you execute manual tests as part of the project, the results can be recycled to build your automated test suite later.
We detail in another article the benefits of automated testing.
Conclusion
Although each of the seven guiding principles can be broken down into much greater detail, the above can serve as a quick reference for your digital transformation journey.
At FINARCH, we have implemented and worked with many of the leading investment management systems and have successfully delivered even the boldest of digital transformation ambitions. We bring decades of experience and a pragmatic view to help guide our clients on their digital transformation journey.
If you are planning a digital transformation project to implement a new investment management system, or your current project has gone off-course, Contact Us to discuss how we can help.
