This blog continues the prior French-themed entry offering basic tips for launching a data management organization. (If you missed the first blog entry, I quoted both Emile Zola and Victor Hugo. There will be a test.*) You might recall that a few well-meaning blog readers had done some finger wagging at me for not addressing some of the basics of data management, particularly when it comes to formalizing the function organizationally, so I offered a few helpful tips to get people started. To review the tips so far:

1: Think local. Don’t boil the ocean.

2: Choose the right team. The right skill sets can make or break a nascent data management effort.

3: Keep current with business initiatives. Have one eye on upcoming business initiatives so that you can support them with data--and force managerment to argue why this isn't important.

Here are three additional tips to round out your data management

4: Know your company culture. It’s all well and good to form a data management team and start tackling dirty data and creating a platform for MDM, but if your company has a consensus-driven culture, you’re probably not doing yourself or your team any favors. Know how to make the case for data management and data integration. Often this means adhering to corporate standards for business case development or cost-benefit analysis. Even if you have a “let’s just build it” culture, you’d do well to make justification for data management more than a back-of-the-napkin exercise.

5: Plan for problems. Stuff happens, so risk management is always a good idea. Have contingency planning for unavailable platforms and people, know what to do if a tool doesn’t work right, have an escalation plan for wrong results and inexplicable data erros, and do “what if” scenario planning using your initial project plan as a baseline. Not only will this help you when the inevitable problems arise, it will demonstrate to management that your data management planning has been experienced-based and sober.

6: Think big. Often, we’re beholden to management that doesn’t understand what we do, to existing development methods that don’t cut the mustard, or to business users who question our value. We get saddled with data projects that might not be within our scope, but that developers or other teams couldn’t handle. One of my clients recently had to support a point-to-point data integration effort, when it was exactly these type of efforts the new organization was trying to eradicate altogether! In all these cases, data management teams should be continuing their “internal PR,” keeping upcoming projects on everyone’s radar and proselytizing the value of information.

The point is to define potential improvements, measure success, know the risks, and keep one eye on what’s next. It’s good advice for any IT project, but especially germane for data management.

* Yeah, but it could be worse. I could have quoted Flaubert. But then I’d get a new group of readers I hadn’t bargained for, and if you’ve read Flaubert, you know it’s simply not worth it.

I’ve gotten several well-intentioned e-mails from some blog readers who’ve accused me of targeting experienced data people. The e-mails gently suggest that I consider beginning at the beginning. They say something along the lines of:

“Hey, thanks for discussing customer data management and data governance and Information Centers of Excellence and the business value of data integration, but… we’re new to all of this. We don’t have any kind of data management in our company. It’s all being done by application developers in a one-off way. Heck, we can’t even get our management to fund a data modeler! Where do we start?”

The great French writer Victor Hugo once said, “Nothing else in the world…is so powerful as an idea whose time has come.” Perhaps you’re ready to establish some formal data management practices. In this blog entry and the next, I’ll provide some helpful tips to consider before going to management for support and funding:

1: Think local. It’s dangerous to pitch a big, behemoth, mother-of-all-data organization out of the gate. Better to identify a specific, consistent business problem that can be fixed with data, and fix it. Then show the benefits, and grow your data team from there.

2: Choose a good team. Just because someone understands technology doesn’t mean she understands the data that supports the business. As you begin formalizing data management practices, look for people who not only understand the business need for data, but ideally for those who have actually used that data to solve business problems. Round out your data management team with specific skill sets like data modeling, metadata management, and data quality. This might mean hiring from the outside, or retaining outside expertise to train your internal staff. Whatever you do, don’t succumb to the “warm body” syndrome that could doom your data management team from the get-go.

3: Keep current with business initiatives. The biggest sin of even the best data management teams is that they don’t keep business strategy on their radar. These teams go into their holes, focusing more on design conventions and metadata repository solutions than on new business initiatives hurtling through the strategic pipeline. CRM projects come to mind here: Show me a data management team poised to support customer-focused initiatives with data, and I’ll show you a data management team that will have no trouble securing ongoing support from the business.

In the next blog entry, I’ll talk about your company’s culture and why it matters in configuring a data management organization. This topic could be a novel worthy of Victor Hugo, but I’ll try to keep it short and sweet.

I’ve been writing and webbing about CDI for a number of months now. This week I gave one of my first in-depth seminars to a cross section of Bay Area professionals interested in reconciling CDI with the rest of their data enabling technologies.

The seminar—part of a three-city tour organized by the BI Network and sponsored by DataFlux—kicked off at San Jose’s Museum of Technology. DataFlux CEO Tony Fisher opened the session, doing his usual comprehensive job of covering the business drivers of integrated data. Tony described CDI as transcending the “single view of the customer” claim that it rightly owns. He offered a maturity model for Master Data Management and described each phase in the MDM capability continuum. Not to put too fine a point on it, but this guy runs a company AND he can talk about master data hubs.

Speaking of smart executives, Peter Harvey, founder and CEO of Intellidyn (www.intellidyn.com), presented a fact-filled case study describing how Intellidyn’s data reconciliation capabilities—fueled by the DataFlux matching engine—help the marketing services company deliver superior consumer data to its business customers. Intellidyn has become one of the few best practice companies in a space that is still so nascent that the early adopters are still adopting! No surprise that Inc. magazine named the company one of America’s fastest growing privately-held companies.

My talk was about why CDI has staying power. I like it when workshop attendees take notes—and the ink was flowing—but I like it even better when they ask questions. I’d anticipated inquiries about architecture and data models. To my surprise, nobody claimed, “We can do all that with our data warehouse!” I was beginning to think there wasn’t as much missionary work to do as I’d thought.

But then the questions began in earnest. Someone wanted to know how to leverage CDI to position more formal data management roles. Someone else asked for ways to position CDI to management as an analytics enabler. A group of people took me aside at the break and asked if CDI could help them redeploy their ETL programmers. And there were scads of questions about data governance.

Don’t worry—my final slide referred everyone to this blog, where there are as many answers as there are questions. If you happen to be in Dallas or New York, come and see us! Here are the coordinates: www.b-eye-network.com/dataflux/.