Recipe for Successful Implementation of PMAR Systems

Every year the global buy-side industry spends millions of dollars in new system implementations across their front, middle and back office functions. Asset owners, asset managers and wealth managers intend to use either an integrated back to front office platform or a best of the breed software package (either licensed or internally developed) to run their middle office processes, however at times they fail to implement it successfully as per their requirements due to various reasons.

Having steered some big-ticket system implementations for our clients in Asia, the Shoreline team is truly aware of the challenges that comes along the way. As part of the implementation best practices, we have come up with our own recipe for successful system implementations for the middle office functions particularly a performance measurement, attribution & risk (PMAR) system.

  • Requirements Gathering: A high and low level of analysis of the business requirements is a foundation for setting up a baseline expectation for any new PMAR system. Towards the end of assessment stage, all stakeholders should be unequivocal about the scope of work and the success criteria of the implementation engagement. Apart from the various minute level details, the requirement document should broadly capture the following details:
    • Inventory of portfolios, composites, indices and benchmarks to be set-up initially in the new system
    • Source and format of upstream investment and reference data like security reference data, FX rates, prices, holdings, transactions, risk free rates, total & constituent level index data and analytics (for FIA)
    • Matrix of various total return, performance attribution and GIPS composites calculation configurations tagged to each in-scope portfolio & composite respectively
    • Infrastructure requirements
    • Data Governance framework
    • Timelines
    • Testing methodologies & sign-off criteria for UAT & Production Go-live
  • Project Management: Any project which overshoots timelines and budgets is considered a failed implementation no matter what incremental benefits it brings on-board eventually. As they say assumption is the mother of all evil in any system implementations, so all high-level assumptions should be vetted on time. Comprehensive documentation is also required to bring transparency and control while achieving project goals and objectives.

Project Managers should maintain standard artefacts kit covering requirements backlog, work breakdown structure (WBS), functional specification, technical specification, a runbook to list down all customization executed for migration purposes and finally a handover guide for business users. There should be frequent touch points in the form of bi-weekly stand-ups, workshops, walk-throughs and steering committee meetings between implementation team, business users and Project sponsors to keep a tab on the overall health of the project. Project plan should factor-in all possible contingencies to honour delivery timelines. The whole above approach can be aligned in either of the SDLC models (waterfall or agile or a hybrid one). Let’s save the SDLC choice debate for another blog.

Many clients want to achieve 100% automation around ETL layer and data validation process right on day one. Sometimes clients also want to leverage the implementation window as a disguised opportunity to clean-up years of historical bad  quality investment data. Both agendas can create conflicting priorities and hence should be carefully treaded by the PM to avoid any cost and time slippage.

  • Personnel: People play a major role in defining the success of any PMAR system implementation. Members of the implementation team should have a strong grip on both product functionality and the investment data domain and they should also exhibit a deep understanding of client’s business & technical requirements. The consultants should exhibit excellent communication, problem solving and project management skills as well.The client should also plot some key resources from their own department(s) who can act as a bridge between the core implementation team and the business users. Remember a successful implementation is always a team effort, it’s difficult to achieve the desired outcome without an active support from all stake holders.
  • Process: Well-structured business processes and consistent department policies goes a long way in setting up solid foundations for software implementations. Having a robust peripheral supply chain of investment data around the new system is paramount to the success of the implementation. Consistent treatment of accounting rules, corporate actions validation, cash flow timing, performance locking period and other data validations through control reports and maker-checker model etc. can ease off downstream attribution implementation headache. System implementations should always target reduction in dependencies on manual interventions in the regular data processing workflow.

“A day in the life” process for PMAR production >>

During implementation phase, both business users and client’s IT team should impart solution knowledge transfer very seriously. During UAT the end users should test the system rigorously from data sanity and system performance aspect. All regular BAU, seasonal and outlier scenarios should be given adequate coverage before giving a UAT sign-off.

  • Product: The system should be loosely aligned with client’s future operating model and the client should have some form of visibility over vendor’s development roadmap and upgrade frequency. Any ideal PMAR system (whether best of breed or an integrated front to back office platform) should extend coverage to multiple asset classes and should be able to offer the following off-the-shelf calculation and configuration functionality:
    • Various combinations of total return computations via TWR & MWR methodology
    • Top-down and bottom-up equity & multi-asset attribution via Brinson Fachler & Brinson Hood Beebower methodology with tiered classification model option
    • Fixed Income Attribution (FIA) via Campisi, Van Breukelen or Timothy J. Lord model
    • Various ex-post risk adjusted performance metrics
    • Drill-down capabilities till security level
    • GIPS composite construction and maintenance

Besides all the above, the system should have an intuitive interface for business users. It should offer both buy-hold and transaction based analytics processing, it should also offer various in-built data validation checks to flag bad input data. It should allow retrieval of audit trail of all data and configuration level changes made on the front end along with user and date/time stamp. Having a highly customizable data import design to allow system integration with various multiple data sources like accounting, index, security reference master, fixed income analytics and client reporting suite will be extremely helpful for the client particularly for running BAU processes and scaling up the portfolio and calculation universe at any time during the lifecycle of the system’s licensing agreement. The system should also offer a crispy reference guide for users explaining all their calculation methodologies, standard use cases, system parameters and other specifications.

However, it must be kept in mind that despite umpteen data quality control and validation checks, any PMAR platform still has a major dependency on clean and polished upstream data and that’s what makes the implementation of a PMAR system unique and also more challenging than other system implementations. Getting the investment data right is paramount to achieving an uncompromised level of attribution engine output.

Saurabh Kumar

Senior Consultant

Share This

Copy Link to Clipboard