“Ideas are a commodity. Execution of them is not.” Michael Dell

In this blog series, we’ve explored Step 1 – Planning and Step 2 – Expertise. Now it’s time to talk about execution. Let’s put that plan and expertise to work. And yes, something unexpected will happen. It’s enterprise software, after all. That’s ok, planning for the unknown is part of the plan too!

The fundamentals of executing a plan include setting objectives, defining tasks and timelines, assigning resources, and tracking progress. Everyone knows that. But what separates a successful project from an unsuccessful one? Execution. It comes from two factors – expertise and diligence. Knowing what tasks need to be done, and setting the right time frame to accomplish them, takes expertise. When a task is underestimated, it usually results in delays or under-delivery. Let’s explore a few areas of cloud MDM migration that are difficult to execute and can lead to delays or under-delivery. 

The first is business rules. The business logic of the current MDM system needs to be described in detail. This isn’t just documenting product manuals and previous implementation notes. A thorough understanding of your MDM rules comes from actually using the functions and documenting their behavior. There will always be undocumented behaviors that must be observed and noted for the migration plan. Once all business logic is fully understood and described, it can be evaluated against the cloud MDM solution. This is a second area where under-delivery or delay is a risk. The cloud MDM solution may not have the same business logic as the on-premises MDM solution, and the implementation of new business rules and processes may be required to achieve the same business process. If corners are cut, adoption may suffer. The last thing you want during a cutover is business users saying “the new system is breaking my business processes – I can’t use it!” Having the experience in MDM business rules and how to satisfy business requirements with cloud MDM solutions is one of the keys to successful execution. 

The second is data anomalies. Yeah, I know what you’re thinking. “Isn’t an MDM system supposed to be the golden record – a pristine and near-perfect data record?” Not in the real-world. Data may be loaded into MDM with anomalies, missing values, and incompatible values. Sometimes data loaded in a batch may bypass some validation or quality rules. Sometimes, it doesn’t get corrected later. Life happens. MDM data records aren’t perfect. But it is surprising how often data is migrated from an old to a new system “as is”. There’s a tremendous opportunity to fix those anomalies during a migration – and it has to be part of your migration plan. Besides, having even better data in your new cloud MDM solution is a good selling point to your end users. 

Third, let’s talk about testing. All too often, testing isn’t expansive enough. It is related to the first point of expertise. A deep understanding MDM functions, rules, behaviors, and use cases is necessary to plan a thorough set of test cases. Experts who have migrated MDM to cloud before have that experience and those test cases at hand. This is an area where your plan can go late and incur more budget. Remember this – the best of the best, test test test!

Cloud MDM migrations are challenging. Great plans built from experience are nice, but relentless execution is golden. In all my years implementing and migrating MDM, the one principle I’ve always followed is this – customer success is the only objective. I’ve always been committed to executing the plan above all else. I think it’s the only way to approach challenging projects such as an MDM migration. No matter who you partner with, make sure you evaluate their ability and desire to execute. If you’d like to learn more, read our best practices for MDM cloud migration and try our migration readiness assessment below.