Project Success Story: The Headache of Upgrading Legacy Systems

By Linky van der Merwe

Success Stories SharedThe story is about a multi-year project for a Credit Card Decision Engine upgrade for a Tier 1 Financial Services company. The upgrade was for a legacy application that was never upgraded since its inception, 10 years before.

What made it complex, is the fact that much in-house customisation was done on the system, which was mostly undocumented. The technical teams had to do a deep dive analysis to decide what parts had to be upgraded and which had to be decommissioned. All new customisation had to be supportable, under warranty. It was a 2-year project that was fully outsourced with 20 off-shore team members as well as an in-house team.

Agreement and Commitment

During the Analysis and Design Phases, extensive analysis was done and the project manager (PM) ensured that the business signed off on each part of the required functionality. No development was started until sign-off was obtained. This covered the project team if the business changed their mind later on.

The project team had a strong technical lead and a 100% commitment across a very technical team, consisting of outstanding senior analysts, with great skills. This made it much easier to manage such a big project team.

The PM also worked with a client project manager who cooperated very well and was very professional, and had a very good depth of knowledge for a Business PM.

Challenges

Headache of legacy system upgradeMuch over-time work was required towards the end for User Acceptance Testing (UAT) due to business resources not being available when required.

About 3 months’ worth of business user testing was required. The project team had to work over week-ends to make up lost time. There was an external deadline that had to be honoured. There were also dependencies on this project from other projects.

The technical resources including off-shore based team members, needed to have face-to-face workshops with the client while doing analysis. Much preparation was required for bringing offshore resources to South Africa. They had to stay from 2 weeks to 3 months and some found it hard to adjust to local circumstances. One female in particular struggled being away from her family for cultural reasons, and as a result had to return home after only 2 weeks.

Lessons learnt

If the technical team tells the PM that minimal time is required for a certain activity, then the team needs to be trusted to deliver on that estimate.

It’s important to obtain full and formal commitment from the business client. Timelines can only be honoured if the client provides the required test resources. Non-provision of resources on time when required, caused delays.

The fact that business requirements were completed and signed off by the right client resources, meant that any changes to requirements later on were treated as change requests on the project. The scope was agreed and understood before the Build phase started.

If there is an outsourced component working on the project team, who is not dedicated to the project, there is more risk regarding timelines, resource allocation and delivery. This has to be managed closely.

Also be sensitive to helping offshore resources adapt to local circumstances. More should have been done outside of work to make it easier for them to adjust to local circumstances.

*******************************************************************************************

Jason Ingel is a project manager who started out as a developer, then a team lead. He has been involved in projects for more than 9 years.

Jason can be contacted on +27 76 439 1921 or via email at: jasoningel@gmail.com

print

Leave a Reply

Your email address will not be published. Required fields are marked *