Could External Quality Assurance Hamper Your Chance of Data Migration Success?

I’m not sure of the exact rate for failures in data migration projects. Along the way I’ve seen Gartner report that somewhere around 83% of migrations either fail or overrun budgets and schedules and if memory serves I believe I’ve read that Forrester reported the success rate at around 16%.  The exact number probably depends upon who is doing the reporting, whom they survey and how candid the responses they receive are. Whatever the case, the number is big, scarily big.

To my way of thinking any area of a major project where the weight of historical evidence suggests that somewhere between 8 and 9 of every 10 attempts will be significantly challenged should be subject to two things:

•  External quality assurance processes in an attempt to make sure that the chance of success isn’t derailed by things not being done as they should. Adding another voice of experience or another set of eyes if you will; and

•  Some form of contribution to the wider data migration community of practice to help understand where things go wrong and over time (as a collective drawing from the positive and negative experience across many projects) look to evolve the methodologies used to undertake data migrations and lift the success rate.

Unfortunately, at least in my experience at least, the two items often work at cross-purposes. All too often I’ve seen the first endeavour block or even derail the second.  Quality assurance efforts will often be established as a risk mitigation exercise. That same aversion to risk often results in lack of comfort and confidence in anything which can’t be shown to have been done many times before. An established methodology is preferred over that which might be construed as cutting or bleeding edge.  That’s all well and good but, chances are, if you are following an established approach then that approach has been followed by a fair number of those 83% of projects that failed (to some degree) before yours.

This resistance to any attempt to stray from the well-worn path hinders the adoption and evolution of new concepts in so doing prevents them from gaining wider acceptance, development and enhancement over time by the wider crowd of data migration practitioners.

So we, as those practitioners, have two choices. We can accept that we can do little to change accepted practice, keep our heads down, collect our pay cheques and hope that luck or our best efforts place us in the lucky 17%, or we can look to find ways to not only increases the chances of success for our project but also contribute to the longer term average success rate of data migration projects in general. If we do want change then we must also recognise that radical shifts in methodology just won’t be possible; governance and quality assurance processes simply won’t allow that. Instead I think we must look for chance to use new techniques to build upon more accepted methodologies, filling the gaps or shoring up the problem areas that pose the biggest problems in our particular current projects.  This could take any number of forms from using lead indicators alongside lag indicators to build gradually build confidence across a project or the gradual introduction of new and improved approaches to the techniques and timing of reconciliation. 

Whatever, and however, we may go about this I hope that over time as a community of practitioners we can slowly build acceptance for new techniques, new methodologies and new measurement paradigms and over time slowly shift what is deemed to be acceptable and common practice. Who knows, maybe sometime before the end of my career we may actually see a failure rate that doesn’t send cold shivers down the collective spines of project managers everywhere. 

Congratulations, Your Data Migration Project Was a Success! Or Was It?

In recent years I've begun to notice something amongst data migration providers that I'd seen little of before. Many of them (or at least many of those that I've had dealings with) are beginning to be far more proactive in taking steps to ensure that their migration projects are successful. That's a good thing, isn't it? Well I guess that depends how you define your success metrics. Does a successful migration always translate into benefit (or at least lack of significant pain) for the enterprise?

Perhaps the most noticeable shift has been towards the "less is more" philosophy. That is, rather than trying to take all of the data that's available, or that the business users say they need, there is a push back to reduce the amount of data migrated between systems. In my opinion this is a good thing - not migrating data that isn't required should remove complexity, decrease cost and time lines and, perhaps most significantly, reduce the risk of unexpected problems leading to delays and cost blowouts. For me there are a number of scenarios when this approach makes a lot of sense:

• Some of the data can be shown to add no value to business operations (that is it's only required for compliance or records management requirements) AND the business users agree that this is the case;
• There have been several past restructures to business operations resulting in data which is very hard to map between different charts of account or the like;
• The cost of migrating the data is significantly higher than the value that having it available in the new system would deliver AND not migrating it does not expose the company to any significant additional risk.

However, I've seen other arguments for this approach, among them:

• Only open balances and other current data are required for the business to operate;
• Migrating anything over and above current data introduces more cost and risk of project time overruns;
• It will be more cost effective to use alternate means (other than migrating it) to get to old data, including:
• Leaving the old system in place in a read only state;
• Leaving the old data available via a an existing data warehouse or BI solution;
• Leaving (just) the database from the legacy solution in place and having IT staff query it to service user requests.

There's a common thread amongst these items - they all focus on a successful project outcome, i.e. getting the project delivered on time, whilst making some major assumptions about life post migration. So, if you're faced with a migration project where your vendor is proposing this style of approach, or even if you yourself are considering this option, take some time to validate those assumptions. Ask the business users if they really can operate on that minimal data set. If they say yes then ask them some more questions, paint a picture of how the world well be and test their theory - how will they do trend reporting, how will they respond to an e-discovery request, how will they bring a new product to market quickly or design future sales and marketing campaigns in a timely fashion?

Don't just talk to the business users, spend some time with the IT folks as well. What's the impact to them of having to keep old systems around for some (potentially significant) amount of time? Chances are IT Management won't have budgeted for having to continue to pay licence fees for the old software on top of the new fees, let alone the operational support costs of keeping the computing hardware that it runs upon up and running. This can be made worse still if a third party supports this hardware and requires that it be kept in warranty as then there may well be new hardware purchases, product installations and potentially even a migration of the old system (to the old system) as well. And then there's the need to maintain support and help desk skills with the old products. At best this means having to keep staff cross skilled, potentially reducing their ability to perform higher order work, but it may also mean the need to bring on new staff, adding head count and increasing wage costs. A tricky situation becomes even worse if the project business case doesn't recognise the need for increased IT operational spend or projects IT savings from the increased efficiency the new system will bring. 

Only when you've satisfied yourself that the assumptions are understood and hold should you proceed with reducing the data migration volume. Chances are there will be a middle ground where the data required is more than the bare minimum set and both the business and IT can operate without significant compromise - aim here! Hit this and there's every chance that your migration project will be seen as successful not just at go-live but also in the weeks, months and years that follow. Aim for the minimum migration set, without first validating the approach, then enjoy the accolades at go-live, but hit the road in a hurry because it won't be long before both business and IT managers are queuing up at your door to ask some hard questions. Good luck!

Technology Leadership - A Misnomer?

If you've had a career of any reasonable length in the IT industry and have a track record of success behind you then chances are you're now in, or at some future point will be offered, a role which is considered a Technology Leadership role. In the data and information space these types of roles include Architects, Business Intelligence Managers, Competency Centre Leaders, Data Quality Managers and the like.

I've worked in many of these roles at various times and the one thing that they all have in common is that often this so called technology leadership is actually dealing with issues that have little to directly do with the technology at all. Rather the Technology Leader spends his days strategy setting, looking for ways to deliver business value through future change or the current actions of his people, engaged in stakeholder management, selling concepts to senior management, and so on. Most of these issues are actually more closely aligned with managing functions, people, shaping programs of work, etc and require some ability to control and direct and have access to, and authority over, budget and resourcing decisions. Without this the leadership may become divorced from the ability to deliver which can have serious ramifications on credibility, influence and ability to show effect and value from the leadership role. Perhaps it could even be argued that people in such roles are shouldering, and in some cases having to own, some of the concerns traditionally associated with line management without having enough say in solving those problems - i.e. their plans could be quashed, derailed or rerouted by others who do have control over budget, resourcing or strategy.

In order to allow our technology leaders to add the most value we need to realise and acknowledge their leadership is in fact only in part technology based. Our technology leaders need a seat at the management table to be truly effective. Taking this step delivers another benefit. Technology Leaders are in the decision loop early, ensuring better alignment with other initiatives and allowing others in the management structure better visibility of, consideration of, and therefore use of the area from which the "technology" leader comes.

The alternative to this arrangement is the introduction of Thought Leadership roles. These may well be ideal positions for the person formerly known as Technology Leader if the organization can stretch to that. However most can't due to lack of size, true need, commoditisation of many facets of the IT function, or shrinking budgets. The unkind (or is that better phrased as jealous?) spin on these roles might well be lots of thinking, musing and sprouting of opinion without the need for implementation efforts hampered by real world constraints and politics. Hey Gartner - if you're ever looking, I'm over here :)