TechnipFMC: Comparing past and present to identify critical success factors
At the most recent Gartner MDM show in Grapevine Texas, TechnipFMC presented a retrospective of their master data management program. It's a successful program. TechnipFMC masters over twenty eight different domains, supports thirty nine different enterprise applications, and supports one hundred ninety eight operating centers worldwide with their MDM program. (For those of you who didn't get a chance to attend Gartner, Mr. Billy will be presenting his talk again in an upcoming webinar on April 25, learn more.)
As I pointed out in my recap post, one of the more unique characteristics of the TechnipFMC program is that we have the ability to turn back the clock and look at what the MDM team was doing back in 2011. On our website, we have the original talk by Jean Luc Brunat that details their early steps into MDM and with hindsight we can see a couple of things that ultimately led to their success.
Where you start does not determine where you finish
One of the more fascinating things about the Technip MDM program is that it started on the analytical side. While their objective was to improve business operations, the MDM team (in consultation with the business) felt the best place to start was in reporting.
But just because the team started on the analytical side didn't mean it was ‘stuck' in reporting. In fact, with twenty eight domains (and counting) under their belt it's quite obvious the MDM team has moved well beyond analytical and is now firmly supporting operations throughout the firm.
I bring this up because often MDM teams worry a great deal about their starting point. They are often concerned that the first projects create path dependence. Or, it sends a negative message to the business if the MDM team doesn't try and tackle those "big, hairy, audacious" domains first. The Technip experience runs counter to many of those concerns. Moreover, this iterative approach of domain-by-domain expansion presents an interesting data point on the debate between multidomain and single domain MDM. In the case of Technip it began as a single domain and became multidomain over time. Is it possible that single vs multidomain is simply a matter of perspective?
An early focus on confidence building measures
Successful first projects create the trust that's required to tackle those next domains (especially important if those big, hairy and audacious domains are next!) In Jean-Luc's presentation from 2011, we see the effects of their early successes. Other groups in the business came out of the woodwork once they learned about (or experienced) the value MDM created.
Additionally, the best part of focusing your first MDM projects on specific teams is that your business customers become great internal references. Often these business users can quickly and concretely identify the small (and innumerable) ways that accurate and consistent master data has improved their day-to-day. That personal message and testimonial is compelling for other teams and helps create interest in the program for other teams.
Make participation a priority
Without a doubt enthusiasm and excitement can feed into the success of a program. However passion is not enough to sustain a program over the long haul. For example, John Radcliffe (Gartner MDM Analyst, emeritus), writing several years ago, observed that many MDM programs have fallen by the wayside as their passionate internal champions moved on to new roles. To mitigate this "key employee risk," the Technip team designed an organization to nurture and sustain that passion.
In the organization, the business teams and the technical teams share the same management. Common leadership helps ensure unity of effort and aids in coordination. Additionally, we see how this structure "bakes in" a method for perpetuating the program: the information management team ‘responds' with new data services as they receive new requirements. This mechanism does a couple of things, it continues to reinforce and deepen the trust between the business and technical teams with each requirement satisfied. And, over the long term, this interdisciplinary approach results in cross training: the technical teams become more well versed in the business and the business teams become more well versed in the technology. As I mentioned in the previous post, our speculation is that this organizational approach (and the cross training that it facilitates) is one of the reasons why the centralized MDM team has shrunk over the past six years. Simply, the business has taken on many of the MDM related responsibilities that would traditionally have been managed by the program.
Your organizational needs, not your MDM solution, should determine your deployment style
Finally it's worth noting that in 2011 the team realized that they would need to implement in a multivector fashion. As Jean-Luc points out they anticipated that the MDM would need to support a centralized, registry and coexistance styles in order to meet the needs of their business. That said, six years on, Mr. Billy reports that nearly all domains are being supported via the centralization style.
One reason why we may be seeing a difference is that the 2011 and 2017 presentations are snapshots of the same program at different points in time. In the 2011 presentation, it was early days, in order to achieve success quickly the MDM program needed to adapt to the existing business processes and IT ecosystem requirements. This meant choosing from registry, centralization, and co-existance to satisfy the needs of their enterprise applications. With this foundation in hand, Technip team had the time (and trust) to migrate towards a more optimal process and MDM implementation style, ie. moving nearly all domains to a ‘centralized hub.' Perhaps this means programs aren't really either single-vector or multi-vector, but rather they can begin as multi-vector and evolve to a style that best fits the organization.