And why does it develop? Well there is a tendency on the part of the technical staff to appear to take ownership of the problem. They have the technology, they speak a strange language about 'Data consolidation', 'Referential integrity constraints' and 'ETL tools suitable to a CRM environment'. They are also the only ones with access to the new platform and seem to understand it better than the end users.
Best to leave them to it then.
On the other hand the techies do themselves no favours by keeping the end user population at arms length. They are focused on the technically challenging aspects of reverse engineering data structures out of a gnarly old in-house developed system, establishing their API to the new application, configuring and bench testing the ETL tools etc. etc.
So Data Migration is their problem then? Well yes and no. In all but the smallest and easiest migrations it is the dreaded data errors that kill you. These are a combination of semantic misunderstandings - fields used by ingenious end users for purposes that were never intended - and the legacy of every system crash, upgrade, bug and in-life fix that a legacy system has been exposed to. It’s a bit like cheap wardrobes - they're fine in situ but when you move house they fall apart.
When it comes to these types of issue, the IT guys have to go cap in hand back to the business folk and plead for assistance. But guess what? At this point everyone in the enterprise knows that 'The migration is in trouble'. And, not too surprisingly, the smart cookies in the business know better than to embrace a disaster. It's far too career limiting. So they back off.
We then have an all too familiar stand off. The technical section by now have de facto responsibility for 'the migration' but the business side have the de jure right to prevent the migration going ahead! Indeed the IT team may have their bonuses hanging on successful completion of the migration but they lack the authority to press the start button!
Having got ourselves into this impasse how do we get out of it? Well as the farmer leaning over a gate is reputed to have responded when asked for directions 'If you want to get there you're better off not starting from here'. And the rest of this blog is going to describe one technique that, if used early enough will make sure you don’t get into this predicament in the first place. At a future date we will discuss ways of getting out of the mire if you find yourself in it in the first place.
First and foremost you have to have written on your heart the slogan 'Data Migration is a business not a technical issue'. Sure we need technology. But it is an enabler not the reason we are doing the job in the first place. Behind a migration there is always a business need and (hopefully) a tangible business case. Before we put hand to mapping sheet, before we select the technology, before we do our landscape analysis, establish who in the business owns that business case and make sure that they are tied into the successful execution of the project.
To do this I use a technique that I call System Retirement Policy Creation. (I have to change the name sometimes where it's not a system being retired but data moved out of one system and into another - but that's another story). As a first step I ask the guy behind the business case for all the conditions that must be satisfied before we can start to move the data. I do this up front when the prospect of the actual migration is but a distant event beyond the horizon of business immediacy. Of course I have to help with a few prompts - what level of audit/history/training/testing etc will they need to sign that decommissioning certificate? And I accept that the answers at this distance are hazy and will probably change. Indeed the system retirement policy is expected to evolve, as the total solution becomes clear.
The point is to make the migration real to the business owner, get them involved from the outset in owning, not just the successful outcome of the migration, but also the steps along the way that will get us there.
You can even, at this point, suggest setting, as personal objectives for some of the operational guys, the successful completion of the migration.
Then when we get to the tricky bits we are one team. We have not allowed the gap to develop.
Now I know that many people have found their own way of closing the responsibility gap when you find it. Perhaps you could share them? I will, as I say, return to this in a future posting.
