Managing a Data Migration Rescue project

01 May Managing a Data Migration Rescue project

Performance stands out like a ton of diamonds. Non-performance can always be explained away – Harold S Geneen

 

Gemini_Astro_Rescue

Gemini_Astronaut_Recovery

So, you have been tapped on the shoulder to step into a Data Migration project that is failing to achieve it’s objectives –  what are the things to watch out for, what do you need to be wary of, what do you need to do?

I have worked on countless Data Migration Project rescues over the last 10 years, and this work can be exhilarating, draining and frustrating (sometimes all in the same day). The great challenge comes from being called into the project half-way through – the lack of time and forced re-planning often results in rushed results, missed opportunities to do the job as well as possible.

Over the next couple of blogs I will detail several options and strategies that help to ensure a problematic project can get back on track, and to help you, the Data Migration Lead, to not only survive the experience, but to thrive

As a starting point, and remembering that all Data Migration projects are different, apply your judgement to the emphasis that you give to different issues.

  1. Why am I here? What is the crisis that called me in?
  2. What are the measures of success – for the project, for this “section of work”?
  3. Dates, timelines – when are the deliverables required? Is there a Test run?
  4. Who do I need to work with? What resources (time, people, materials)

 

Often, the project is in a state where these are not apparent, due to varying levels of chaos.

It is critical to understand the reasons why the organisation has decided they need your expertise on board at this time in the project – especially when they may already have an experience Data Migration resource in place. This is perhaps the most important consideration, and should be the one target that you ensure you compete by Project End.

You should also understand the deliverables, business impacts and the culture of the team you need to work with. I would say that unless you understand and can document these, you should not take on the project! Of course, there will be many other problems lurking behind this one, but until you have a plan in place to solve this, the rest can wait.

On a recent project, I was brought in to ensure the Financial Transactional data transform was successful for a mid-sized Australian Organisation. The ERP system was up and running, the General Ledgers Account data was in place, Master Data was in reasonable shape and Staff training was happening, but half way through the plan, the Transactional data – Accounts Payable and Receivable had not been started. So, Rescue Time!

The core requirement was to build a decent set of A/P and A/R data for the Trial Load, within 12 weeks! Fortunately, the Master Data (Materials, Customers and Vendors) were in place, in reasonable shape (not cleansed, but ‘Loadable’) to the new ERP system.

Coming on-board, this was the key point – what was an acceptable Load Percentage? We eventually negotiated to 85% of (open) A/P and A/R for Trial 1, 97% for Trial 2 and 99%+ for go-Live. (Without a visible target in place for success, as a consultant you are leaving yourself in a vulnerable position to resolve problems at the tail end of the project).

The timeframe meant that an initial 85% success rate was a stretch, given only minimal work was in place. But with an achievable target in place, agreed by the Project Manager and myself, we had a much better shot at a successful While we did miss the 85% goal for Trial 1 (we were still locking down the rules on what constituted “Open” and Customer de-duplication was causing load failures), by Trial 2 we were just under the 97% mark. With the final adjustment of the transformation rules, and quarantining of a small set of A/R transactions into a manual load, the final result was 99.82% of over 18,000 A/R & A/P transactions loaded.

 

In future blogs, I will cover measuring success in a DM rescue project, managing People in the last frantic days, and running Reconciliation during a rescue project.

 

 

Craig Nock is a Senior Consultant for Seed Analytics, an SAP Services Partner, and global provider of solutions for SAP Data Governance and SAP Data Migration. Seed Analytics is a business division of INNTURE Group.

You can contact Craig via e-mail (craig dot nock at seedanalyticsgroup dot com), find him on linkedin (au.linkedin.com/in/craignock), and follow him on Twitter using @craigmnock

 seeds-innture-logo3

No Comments

Sorry, the comment form is closed at this time.