Specialists in Change Management
How to manage a vendor system implementation
Posted 6 March 2021
It is often with great trepidation that managers begin the process of replacing a legacy system. One of the reasons that large trading system migration projects often run into trouble is they typically occur at 10-15 year intervals. Because they are not common projects, many executives tend to underestimate the complexity of changing their securities lending business systems, believing that project teams from others areas of the organisation will be able to manage the change. The project team needs people who understand the business and its systems. This may seem a fairly obvious point but it is surprising how many companies draft in people who have little or no experience of the industry. It is no longer an area which is the domain of the generic project manager, analyst or developer.
The first rule of thumb is to not allow the selection process to become an emotional debate. Conducting an RFP (Request for Proposal) may be laborious but it is the key opportunity to make the right choice. It is extremely important that this is a joint business and IT led process and resources are not spared in analysing each vendor system. Be ready to test the vendors answers in the RFP, have the business users review the system themselves, don’t allow presentations made by the vendor to users to suffice, when buying a new car people expect a test drive, buying a new system should be no different. Thorough analysis at this stage is often perceived to be wasting time and money but this can be recouped many times over compared with a bad decision.
Once a lead vendor has been singled out, a functional GAP analysis of current system processes compared with the vendor system should be carried out. What enhancements might be required of the vendor system to meet the businesses requirement? Companies often have functionally rich satellite proprietary systems that surround the less versatile legacy system. Will the vendor agree to bespoke requirements, how long will it take? Complete reliance on the RFP should be avoided.
The use of formal project methodologies is often derided but projects must have a formal structure which provides a controlled and organised start, middle and end. The steering committee must have an executive decision maker with representation from senior users and IT managers. Inadequate definition and lack of acceptance of project management roles and responsibilities leads to a lack of direction and poor decision making.
Detailed up-front planning lowers risks in the execution phase of a project. It is a common experience that inadequate planning leads to a poor estimation of duration and costs. A fair expectation should be that 50% of the entire project lifecycle (including the RFP stage) is analysis followed by 50% execution. Projects that are light on analysis phase tend to take a lot longer as unforeseen issues accumulate.
IT must not run the project outright, it is always a joint effort and ultimately the benefit is for the business. It is vital that project managers have properly conceived plans, risk and issues logs and these are maintained through the life of the project. The project should be divided into manageable stages for more accurate planning. Many projects only reveal their true status too late due to insufficient measurables and lack of control over progress.
Once the vendor system has been setup in a test environment the IT team will spend a large amount of its time focused on the data migration. This is piece of work which is almost a project within a project and having a separate detailed plan which combines at a summary level into the main plan is often a good idea. A key risk in this phase is the data migration team becoming detached from the rest of the project and working in isolation. The migration of data is one of the most complex parts of any system transition and requires a great deal of expertise. Do not expect the vendor to manage this phase, they will normally only take responsibility for their own systems functional ability to load the data as presented to them, not its outcome. It is very important that the business remain involved with this piece of work, after all it is their data that is being migrated. Often the creation of a conversion database which sits between the two systems can be used to cleanse and transform, an important opportunity for the business to remove aged security and other data which is no longer needed.
The testing phase of any migration must be carefully organised. Project managers must ensure all test issues are recorded in an issues log (plenty of sophisticated software is available but a simple Access database with a report will suffice if nothing else is available). Don’t be fooled by those who tell you sophisticated software can replicate required knowledge in system test conditions. The test team must understand what it is they are testing and what the desired outcome is. Thorough testing is now critical to success.
One of the key pitfalls in most projects is the lack of involvement of the business in UAT (User Acceptance Testing). Many of the key users are either traders, collateral managers or those in settlements who have very little spare time. The executive sponsors need to plan for this eventuality. During the life of a project key people emerge, sometimes a trader, other times an operations supervisor who have a depth of understanding and a natural inclination to become involved that becomes essential to the success of the project. Businesses should plan to support or backfill such people to enable them to engage properly with the project and UAT. Business users are often very happy to moan about a system not meeting their requirements but they themselves will often not have engaged in the UAT process at all.
Full dress rehearsals of a migration should be held until a completely clean run is achieved. This may mean staff in at weekends which is never popular but it is important to nail down unexpected issues prior to attempting to go live. Most transitions happen at a weekend when there is more time to recover if problems occur, often simple issues like the accidental locking down of a server or a forgotten password can scupper an entire migration so it pays to be prepared. It is important to make sure outsourced support functions are alerted to the event, the classic mistake is not realising the building is being powered down on the same weekend as the migration.
Migration projects are challenging, but can deliver great value to end users. Good projects that deliver always have the same characteristics, a project team who have industry expertise and experience in delivering under pressure, a structured approach to the project and a well engaged business.
It is often with great trepidation that managers begin the process of replacing a legacy system. One of the reasons that large trading system migration projects often run into trouble is they typically occur at 10-15 year intervals. Because they are not common projects, many executives tend to underestimate the complexity of changing their securities lending business systems, believing that project teams from others areas of the organisation will be able to manage the change. The project team needs people who understand the business and its systems. This may seem a fairly obvious point but it is surprising how many companies draft in people who have little or no experience of the industry. It is no longer an area which is the domain of the generic project manager, analyst or developer.
The first rule of thumb is to not allow the selection process to become an emotional debate. Conducting an RFP (Request for Proposal) may be laborious but it is the key opportunity to make the right choice. It is extremely important that this is a joint business and IT led process and resources are not spared in analysing each vendor system. Be ready to test the vendors answers in the RFP, have the business users review the system themselves, don’t allow presentations made by the vendor to users to suffice, when buying a new car people expect a test drive, buying a new system should be no different. Thorough analysis at this stage is often perceived to be wasting time and money but this can be recouped many times over compared with a bad decision.
Once a lead vendor has been singled out, a functional GAP analysis of current system processes compared with the vendor system should be carried out. What enhancements might be required of the vendor system to meet the businesses requirement? Companies often have functionally rich satellite proprietary systems that surround the less versatile legacy system. Will the vendor agree to bespoke requirements, how long will it take? Complete reliance on the RFP should be avoided.
The use of formal project methodologies is often derided but projects must have a formal structure which provides a controlled and organised start, middle and end. The steering committee must have an executive decision maker with representation from senior users and IT managers. Inadequate definition and lack of acceptance of project management roles and responsibilities leads to a lack of direction and poor decision making.
Detailed up-front planning lowers risks in the execution phase of a project. It is a common experience that inadequate planning leads to a poor estimation of duration and costs. A fair expectation should be that 50% of the entire project lifecycle (including the RFP stage) is analysis followed by 50% execution. Projects that are light on analysis phase tend to take a lot longer as unforeseen issues accumulate.
IT must not run the project outright, it is always a joint effort and ultimately the benefit is for the business. It is vital that project managers have properly conceived plans, risk and issues logs and these are maintained through the life of the project. The project should be divided into manageable stages for more accurate planning. Many projects only reveal their true status too late due to insufficient measurables and lack of control over progress.
Once the vendor system has been setup in a test environment the IT team will spend a large amount of its time focused on the data migration. This is piece of work which is almost a project within a project and having a separate detailed plan which combines at a summary level into the main plan is often a good idea. A key risk in this phase is the data migration team becoming detached from the rest of the project and working in isolation. The migration of data is one of the most complex parts of any system transition and requires a great deal of expertise. Do not expect the vendor to manage this phase, they will normally only take responsibility for their own systems functional ability to load the data as presented to them, not its outcome. It is very important that the business remain involved with this piece of work, after all it is their data that is being migrated. Often the creation of a conversion database which sits between the two systems can be used to cleanse and transform, an important opportunity for the business to remove aged security and other data which is no longer needed.
The testing phase of any migration must be carefully organised. Project managers must ensure all test issues are recorded in an issues log (plenty of sophisticated software is available but a simple Access database with a report will suffice if nothing else is available). Don’t be fooled by those who tell you sophisticated software can replicate required knowledge in system test conditions. The test team must understand what it is they are testing and what the desired outcome is. Thorough testing is now critical to success.
One of the key pitfalls in most projects is the lack of involvement of the business in UAT (User Acceptance Testing). Many of the key users are either traders, collateral managers or those in settlements who have very little spare time. The executive sponsors need to plan for this eventuality. During the life of a project key people emerge, sometimes a trader, other times an operations supervisor who have a depth of understanding and a natural inclination to become involved that becomes essential to the success of the project. Businesses should plan to support or backfill such people to enable them to engage properly with the project and UAT. Business users are often very happy to moan about a system not meeting their requirements but they themselves will often not have engaged in the UAT process at all.
Full dress rehearsals of a migration should be held until a completely clean run is achieved. This may mean staff in at weekends which is never popular but it is important to nail down unexpected issues prior to attempting to go live. Most transitions happen at a weekend when there is more time to recover if problems occur, often simple issues like the accidental locking down of a server or a forgotten password can scupper an entire migration so it pays to be prepared. It is important to make sure outsourced support functions are alerted to the event, the classic mistake is not realising the building is being powered down on the same weekend as the migration.
Migration projects are challenging, but can deliver great value to end users. Good projects that deliver always have the same characteristics, a project team who have industry expertise and experience in delivering under pressure, a structured approach to the project and a well engaged business.
SEARCH
Copyright © SIX Consulting Services Ltd. All rights reserved. Designer: GMG