Creating A Project Plan For A Private Banking System Implementation

Hi there! You know, as a project manager, the domain I'm in is that of private banking. Private banking is enjoying some explosive growth here in Singapore and Asia. The growing numbers of high-net worth individuals (especially from China and India) are creating huge cash inflows over to the hubs of wealth in Singapore and Hong Kong.

As the private banking business grows, there is an equivalent growth in ancilliary services, such as private banking system implementation and associated services.

After my seven year stint as a business consultant in a large American IT multinational company (with a three-letter acronym for its name), I moved to work in a large European private bank.

The bank was rolling out a core private banking system covering its operations in Singapore, Hong Kong, Geneva and the Chanel Islands. It was a huge undertaking and for us, as the project team in Singapore, there was lots to learn and quite a bit of industry and domain knowledge to pick up. Lots of fun!

I returned to consulting in my present firm after two years plus in the banking industry. Now, I'm in my own element (I still love consulting) and running system projects for private banks.

Recently, I was asked by my boss to draw up a project plan for a new private banking system we're helping to roll out for a private bank. I want to share with you some specifics on how you can do this.

In particular, I want to show you some elements of private banking functional content in the planning process, because I suspect that is not something many project managers know about. I also want to highlight some key pitfalls to avoid when implementing private banking systems that you should watch out for.

1. Get The Scope Right

The first thing I do when planning a private banking system is to determine the scope of implementation. Typically, there should already be a high-level scope of implementation drawn up, in a project charter document. I'd read through that document, fully understand what's need. Some key information to look out for in that document:

  • Project background - what business objectives the project is trying to support, what kind of deliverables are expected.
  • Project scope - what major functions will be delivered by the system, what requirements are to be met by the system
  • Project assumptions - what dependencies and assumptions are in place for the delivery of the project
  • Project stakeholders - the stakeholders who are impacted by the project, particularly who the signatories are, and who will approve the system go-live and mediate any project issues which cannot be resolved
  • Project timeline - the timeframe under which the project is to be delivered, particularly the major project milestones, sign-off dates and go-live date.
  • Project resources - who is involved in the project, along with their roles and responsibilities.

Once the project charter has been understood, I start writing out the scope in a bit more detail, usually at a "functional module" level. For example, for a typical private banking system implementation, we would have the following system functions:

  1. Client On-Boarding
  2. Client Data Management
  3. Investment Profiling
  4. Portfolio Management
  5. Trade Management, under which you have things like cash products, FX, equities, bonds, funds and structured products
  6. Corporate Actions
  7. Other Products (e.g. products from other systems)
  8. Call Reports
  9. Statements (e.g. client statement)
  10. Management Information System and Reports
  11. User Security

I'll talk a little about each of the modules above so you can understand what they entail.

Client On-Boarding - the process where private banking prospects are converted into clients. Private banking clients usually go through a screening process called Know-Your-Client (KYC) and have to fill up an account opening form to be registered as a new client to the bank.

Client Data Management - a customer's data like his demographics, address, hobbies, etc. change over time. This area of a private banking system will take care of it.

Investment Profiling - private banks will usually conduct a fact-find of their client's investment expertise to determine what kind of products they are allowed to invest in. In fact, regulatory guidelines in Singapore stipulate that e.g. conservative clients should not be investing in aggressive products like equity or FX accumulators.

Portfolio Management - very important system functionality in private banks. A private bank (especially pure play Swiss private banks like Julius Baer, EFG) are experts at portfolio management.

This involves taking stock of a client's investments across equities, funds, bonds, structured products, etc. and "re-balancing" them regularly so they align to investment objectives and achieve the best return for the client.

Trade Management - private banking operations staff deal with trade management on a daily basis for their clients. From cash products, FX, equities, bonds, funds, etc. - each of these asset classes go through order capture, confirmation, settlement and fixing, depending on their nature.

Corporate Actions - announcements of voluntary and involuntary corporate actions must be processed by a private banking system.

Other Products (e.g. products from other systems) - there may be other products (e.g. retail loans) which may be consolidated or loaded into the private banking system from an external transaction managemnt system.

Call Reports - a call report is a report lodged by a private banker after meeting with a client.

This is important for sales tracking and for relationship management team leaders to track if their subordinates have met their requisite number of calls with clients.

Statements (e.g. client statement) - very important statement sent out to clients, usually on a monthly basis, so they can see their investment positions, transactions and cash balances.

Management Information System and Reports - many reports can also be churned out of the private banking system for MIS or regulatory reporting.

User Security - the setup of user groups and their user access right / privileges is an important component of a PB system implementation.

2. Business Process Re-Engineering

In any system implementation, particularly for a core backend system, business process re-engineering is an important part of the delivery.

Let's say the private bank used to do client account opening using hardcopy forms. There would be a client account opening form for a new prospective client to fill up, and it had to be scanned and archived.

There would also be investment profilers to gather investment background and expertise of the client - to determine the type of products they can invest in.

With a new private banking core system in place, the client account opening form may not longer be in hardcopy but in the system.

The investment profiler may also be in the system, possibly as a wizard-like interface, with questions the Relationship Manager can just fill up based on the client's response.

Does the business process of client account opening change? Yes, of course it does! And the change needs to be documented.

In the bank, business processes are usually documented using what is called a swimline chart - with roles on the left and "swim lanes" containing task boxes and arrows to show what needs to be done and what kind of work routing takes place.

When I plan BPR activities, I'd factor in workshops for extracting "As-Is" and "To-Be" business processes and their documentation. The bank will need these "As-Is" and "To-Be" views to properly capture operational procedures.

3. Requirements Gathering

The next thing I'd do is to plan the requirements gathering for the private banking system.

I usually split up requirements gathering into two parts. One is what is called "user requirements" and the other is "functional specifications".

The user requirements document consists of high-level statements like "The system should support a document checklist screen which allows users to tick which document has been received from the client", or "The system should provide a drop-down box to allow the user to choose the type of corporate action event being captured".

The consumer of this document is usually the business analyst or end user in the project.

The functional specification document will be much more detailed, illustrating the screens, reports and user-system flows. The key consumer of this document is the developer or person responsible for configuration the private banking software solution.

Functional specifications need to go into a very detailed level. That's because most private banking systems these days (e.g. Avaloq) are parameter driven. So when I have a transaction, it could have statuses like "Pending", "Executed", Cancelled" and so forth.

These need to be vetted with the users to ensure the correct values they want to see are there.

4. Design and Development

The next bit of work is for the vendor or IT programmer to design and develop the system for the users. I won't go into this too much - suffice to know that design and development is usually not the realm of BAs or project managers. It is truly best done by the technical team who understand C++, Java and also the banking software package that's being used.

5. SIT / UAT

Ok, when planning the PB system implementation project, the next bit of work is the testing phase. Testing can be divided up into the System Integration test (SIT) and User Acceptance Test (UAT).

For the SIT, you MUST allow time for the periphery system owners to come in to test connectivity to your private banking system.

I say this is very important because I've been in several projects where the surrounding systems' owners are not very committed to providing test support to the PB department. That spells disaster for the project timeline - as interfaces to other systems is an integral part of every delivery I've been in.

For the UAT, make sure you have the test scripts for the private banking system scripted out in full detail.

These should be down to the level of "User clicks Submit button" and "System displays an error message (insufficient funds)". The clearer your test scripts, the easier it is for the tester to run the test, saving you a lot of clarification time during actual test execution.

Case Study. I once helped to roll out a private banking system implementation for a bank in Singapore. One of the problem areas was testing - many of the vendor's modules were not properly unit-tested and resulted in many, many hours of pain on the user's side.

Something that was tested and passed in Cycle 1, may break and fail in Cycle 2. This means that the vendor did not ensure quality in their builds. The lesson learnt here is that the vendor packaging of your solution must be TIGHT.

Make sure the vendor tells you EXACTLY what is delivered in each release and make them commit to documentation of release notes for each package.

6. Training

Training is typically done just before UAT and involves the preparation of training materials and also facilitation of "Train-the-trainer" workshops to help users understand what they need to do when the system goes live.

Make sure you evaluate carefully what needs to be covered here. I have a sense many project managers leave training as an afterthought - but it is actually quite an important element of project success.

Case Study. I was once in a private banking system rollout for a Malaysian bank where the users had no idea what the system looked like or could do before UAT started. That was NOT a good thing.

For them, no training happened before the UAT. As a result, they got a huge shock when they were exposed to the system for the first time during the first day of UAT.

Comments like "I've never seen a system like this in ANY of the banks I've worked", or "How could this kind of crappy system be considered by our bank?".

So the lsesson here is that you NEED to schedule in time to give training to end users and testers, and the best time to do it is just before the UAT commences.

7. Deployment

The deployment phase is one of the most critical components of a system roll-out project. I typically schedule at least a month's worth of preparation activities to ensure deployment plans are in place and executed during system cutover weekends and post go-live.

For a private banking system, the deployment process is no different from that of a normal system roll-out. The first thing you need is what I call a "deployment runbook".

This is a step-by-step checklist of who does what (down to the minutes) in the weeks leading up to the system cutover from the old system to the new one.

The level of granularity in this checklist needs to be very detailed, e.g. down to the level of "Execute script to cleanse System X tables" and "Execute script to load default values into transaction parameter tables".

Not all project managers will go down to this level of detail - but my feel is that the more granular you go, the better control you have.

The other thing to remember about deployment is the system cutover weekend. This is when you set up and load production data into the new system environment which contains your new system's code.

Operational users need to come in to validate that the loaded production data is in synch with the existing production system. Typically, you'd also do what is a "parallel" run in order to ensure for two or three business days, users key clients and transactions into both the old and new systems and make sure both sides give the same end-of-day balances.

Also, once the new system is confirmed to have the correct balances and everything is in order, someone "upstairs" in senior management must give the go ahead to say, "Yes, let's go-live".

You need to install what is called a "post-production command center" to make sure system issues or queries that come in after the system goes live are promptly addressed and escalated if it is beyond a certain severity level.

8. Key Learning Points

Before I end off, I wanted to share with you, from a private banking system implementation perspective, some of the key pitfalls and learning points you need to know.

In a private banking system roll-out, there are always some key areas which need quite a bit of effort in requirements gathering and testing - simply due to the complex nature of the business transactions involved. They include:

Client Onboarding. You need to get client onboarding business processes and system requirements right, because it is the one area in a private bank that attracts a LOT of regulatory scrutiny.

Regulators (like the MAS in Singapore) love to question why the private bank allows e.g. a risky individual like a Cuban national or someone with dodgy sources of wealth to become a client.

Also, there must be checks and balancers in the approval chain to ensure no one party can be solely responsible for approving the set up of a new clients. Procedures for Know-Your-Client and Financial Needs Analysis also need to be water tight.

Trade Management. The whole process of order capture, confirmation and settlement of various asset classes (equities, bonds, mutual funds, structured products, etc.) form one of the largest components of a private banking system.

I'd go so far as to say as much as 50% to 60% of a private banking core system is centred around transactions.

The good thing about transactions is that once you get the basic trade life cycle flow right for one or two products, it's easy to extend it to the rest of the other asset classes (with the exception of exotic structured products which need their own special treatment). Make sure you devote enough time in your plan to deal with transactional flow and system requirements.

User Security Matrix. I also find the "user security matrix" or the access rights of users in a private banking system to be an IMMENSE task which is often overlooked by project teams.

Please don't leave this as an afterthought and make sure requirements surrounding user access are gathered early, rather than late.

Maker-Checker or Controls. One of the key points about private banking systems (or any system) for that matter is the checks and balances available in daily operations.

For example, you must always have a "checker" who independently reviews and approves a payment transaction keyed in by "maker". I find that these kind of requirements are very important but often left as an afterthought. Don't let that happen in your project.

Wrapping Up ...

I hope the above has helped you understand how you can best create a project plan for a private banking system implementation.

There are a HUGE number of elements in a private banking system rollout, so make sure you read the above to get a broad overview of the key project components, and some of the pitfalls I often come across.

Once you get exposure to several of these projects, you'll start to form your own view of critical aspects of the project and what risk areas to avoid.

That's all I have for now. Until next time, have fun managing your banking projects!

How To Start A Project Management Career

How To Start A Project Management Career Guidebook

Are you wondering how to break into a Project Management?

Would you like to understand how others have successfully switched to a PM career?

Or discover what skills, certifications and domain / industry knowledge are required to excel in a PM role?

I’ve written a practical, easy-to-read guidebook that will help you find your best path to Project Management – one that leverages your unique skills, experiences and career background to your advantage.

Click here to find out more.