Data Migration Team Lead - What are the functions?
Monday, August 11 Hi - I have just finished reading ‘Practical Data Migration’ by
John Morris, which I found invaluable. My career path has taken a
similar course as John’s – programmer, analyst, project manager.
However, I was a late starter in IT with no formal training. I began as
a self-taught VB/SQL programmer. My career route has been a fast
tracked through fortunate contract opportunities which has been
pigeon-holed by recruitment agents as a Data Migration Specialist in
recent years.
My problem is this; whilst not new to the various
elements of data migration, I am unsure as to how to approach a ‘Data
Migration Team Lead’ (not Project Manager) role.
Please could
someone give me an idea as to what I do in my first week within this
type of role and what order they should be addressed?
Assumptions:
• Working within a Shared Services environment
• Numerous customers will be migrating from their legacy systems
• The new system will be a Oracle eBusiness Suite bespoke system
• Migration will be for HR & Payroll and Purchase & Ledger data
• Whilst involved with similar projects I am not a functional expert in HR & Payroll and Purchase & Ledger
• I will have 6 data analysts reporting to me
• Trillion will be used for ETL – I have never used!
• This will be a Public Sector project
Any direction would be much appreciated.
Reader Comments (4)
As ever this is open to personal opinion but one of the first things I would do is to focus on the team and understand their skillsets, characters and motivations.
Ask for their CV's then meet them individually and identify what areas of the project suits their background. Some will be natural business analysts, comfortable with clients, cope well in workshops etc. Others I'm sure will be developers and more technically focused.
You will certainly need to understand the deliverables and dependencies for each phase of the project and assign a resource to the tasks that will create those deliverables.
So before you start assigning tasks to your team you therefore need to understand the current migration strategy (if it exists) and identify which deliverables are in scope for your project. Once you have done this you can start to map out the task dependencies, timelines and the skill type to deliver those tasks. (John's book will be useful here).
If you are unsure of where to start I would recommend a workshop with the customer teams to carry out a "landscape analysis" activity. This basically means you identify the relationships of each key business data area that is in scope, map these to systems than construct conceptual, logical and physical models of the underlying data. By assigning data analysts to specific business data areas and asking them to build out the logical models this should give you some breathing space to define the deliverables and task sequences for the project.
Get your data quality rules process instantiated and ensure that everyone understands the importance of DQR management and is following the correct procedure. The DQR process will form the knowledge discovery and issue management hub of the project so ensure you communicate this well. Remember that DQR's do not need profiling tools to find data gaps, you can find data gaps just from talking to business users so make sure this information is recorded.
Remember, you are the conductor of the team, you don't need to know how to play all the instruments but you do need to know in what order they should appear. If you need more support in this area do contact us again.
As Dylan suggests as a team leader the key is that you have the correct team all working in the same direction using an adopted approach. - as long as you are expeirenced in leading a team in a data migration project you wont need to be an expert in Trillium or be a functional expert in all the data sources.
In your couple of weeks I would focus on a small number of key things:
1. Understand the business drivers for the project.
2. Understand the approach being taken to the project - what methods are being used?
3. What progress has been made on the project to date (are you being brought in at the beginning or part way through?).
4. Assess the blend of the team - do you have the correct numbr of Business Analysts, Source System Analysts, ETL developers etc...
5. Does the client have a Data Governance team in place that manages data or is the team expected to manage that aspect?
Stephen Mills
IBM Global Business Services
Steve Barker says...
Posted 12 August 2008
Thanks Dylan, thanks Stephen - much appreciated!
In your FIRST week as opposed to any other I would certainly avoid technicalities. The main thing on a large migration is:
1) Establish yourself as a leader within the team
2) Establish yourself as the data migration manager amongst your peers (the other managers on the wider project)
It might sound like I am not answering your question but of course Stephen and Dylan have already given the nuts and bolts answer above. My caution is that a Data Migration Lead is still a project manager for all that and the initial impression you make amongst others, particularly your team and the managers of Payroll and HR will be a lasting one.
Will you get hypnotised by the systems landscape and start talking ETL, Oracle, tables and joins ...or will you talk to your team one by one about their personal hopes, fears and objectives for the project and to the business managers about what they want to see from migration besides data just on the other side? What is the project really about for them strategically? What are their priorities within the data ...and more importantly why?
You can tell that I feel there is a pitfall here, and one that I have put my foot in more than once, even on projects where I was ultimately extremely successful in technical terms.
I have a strong feeling that the way a DM Team Lead conducts themselves in their first few weeks is the start of making things easy or hard for yourself politically! Put yourself about a bit, especially in the first few days and try to have conversations, look people in the eye, find out what they want and stay away from the keyboard.
So very, very tempting to face the systems instead of addressing the people. Not because we don't have the interpersonal skills as data or technical people, as some people in business erroneously assume :), but because a new landscape is always a new experience and challenge a tempting draw on our attention.
John Platten
Vivamex Limited