It was a sweltering summer day. I had big plans for riding my horse with friends which involved loading my young horse, Smoke, into our new horse trailer and then driving an hour north to the mountains. I knew that once we arrived at our cool and shady destination, my horse would be quite happy on our adventure. But Smoke was not convinced of the soundness of my plan. At first he was annoyed at being pulled away from his barn, then he became scared, and then angry. No matter what I did, he just would not walk into the new trailer. He weighed 1200 pounds, so without one of us being injured, I realistically could not get him into that trailer unless he wanted to go in. 

In my mind, this scenario is a lot like getting a group of data owners and users to go along with a new Data Governance intiative. As the project lead, you know that if they cooperate, invest their time in meetings and trainings, then their data will be much better, and the company will run more efficiently in the long run. However, the truth is this:  most teams won’t go forth willingly with a plan like that unless they WANT to. And if you try force them -- well, your career might be injured in the process.

So, what’s the trick to getting horses and people to do new things?  Take small steps forward and make sure they have some input in the process.

Over the last decade, I have come to understand that Data Governance is a collaborative and continuous improvement process.  It is not just about purchasing great software and training users. It is really about MANAGING CHANGE. Data Governance changes the way the business manages and interacts with their data, and a successful implementation is about communicating, leading and listening.

• Listen by conducting workshops and asking questions to understand how the business does things today. Ask them how dirty, redundant or missing data and processes are impairing their work today.  During this discovery stage, listen for and acknowledge any  fears they might have. Respectful listening and acknowledgement is the key to turning initial negative statements into baseline starting points for planned improvements.
  
• Lead the business by helping them understand the upstream and downstream impacts of bad data. People want to know "why" are you asking them to change.  Next, solicit their help in the development and execution of the new processes. This creates "ownership" in the plan. It's less likely for a team to be resistant to an initiative they feel they had a hand in creating. And be sure to speak respectfully of participants' efforts. Ignoring or being dismissive of people often leads to stonewalling and project sabotage.
  
• Communicate clearly and frequently about the project's initiatives, activities, tasks, and timelines. People need time to process new concepts - so don't spring new things on a team overnight and expect instant obedience and cooperation the next day.
  

Unless you have great buy-in and a groundswell of support from the very start, it is best to start your governance initiative with one or two smaller projects with quickly achievable ROI's. Small but measurable successes followed by praise and publicity ("talking it up") get others excited about joining your successful program. Avoid using the old-school model of big-bang IT-driven projects spurred by political pressure.

In the end, it took two hours to calm my horse down and convince him that it was OK to walk into the trailer. Had I made the effort to get him comfortable with the new process in short sessions ahead of time, I might have actually been able to rendezvous and ride with my friends that day.

So instead of forcing a team into a new uncomfortable place with a single large goal at risk, invite the business to participate in series of smaller ROI small project successes as a part of a larger program. Once the business has experienced a taste of success, they will move forward as a willing partner, eager for new opportunities to shine and help the company become more efficient and profitable through improved data quality.

Daryl Crockett is CEO of ValidDatum,

​

My phone rings. It’s a call from a person I have never met. It’s a C-suite exec telling me his project team has major problems with their data. Judging from the sound of desperation in his voice, his reputation probably depends on the quick resolution of those problems. Many carefully-built careers have been scuttled by data disasters which often come as a surprise to the project team and their leadership. But decades of fielding frantic phone calls and subsequent project rescue experience has allowed me to compile this list of warning signs that your project might be destined to be doomed by data:

1. Your System Integrator says, “Data is a business problem.” It is common for the System Integrators to marginalize their responsibility for the data. And we all understand that the data is owned by the business. But without the cooperation and helpfulness of the System Integrator, your data will have a very rough journey, and this friction could slow down or even derail your entire project. After all, the only reason you are implementing your software is so that you can get data out of the new system. Therefore, it essential that the focus on the data should be paramount within the project. Data should not treated like a lowly stowaway to be unloaded roughly at the very end of the trip. Data is everyone’s problem.
   
2. You have planned only one test data load before Go Live. Data is fluid. It is the lifeblood of your business. It can also be messy, inconsistent and deceptively complex. It takes multiple load cycles and testing with that data to ensure your data can be loaded correctly, and that the data is behaving as expected in the new system and in all reports, interfaces and downstream systems. If you have poorly timed or insufficient “Mock Loads” in your project plan, you’re headed for a rocky landing.
   
3. You don’t share Data Readiness Metrics and data related issues as part of your regular status meetings. This is sailing blind without navigational aids. Even small issues not reported and addressed early can lead to major course corrections later. The best practice: Have a knowledgeable Data Lead involved from the start of the project to manage and reports on data related activities.
   
4. People are creating “fake” data for use in a formal testing cycle. Using pretend data to test system functionality is like announcing you are ready to sail around the world because you read a book on sailing. Your real data has variability and challenges you cannot even imagine at this point. The collection, filtration, cleansing, transformation and the actual loading of that data will be revealing, likely uncovering a host of issues -- some of which may lead to software configuration or design changes. System design changes in one area can impact other functionality within that system and potentially  downstream systems. Bottom line - the earlier you find these data challenges, the more time you have within your project schedule to adjust for them.
   
5. You don’t have a written Data Validation Strategy. Data Validation is a process for determining that your data is complete and correct – as determined by the Business. It is a distinct set of planned, auditable activities that should start before functional testing (Iteration Test Cycles and User Acceptance Testing) and should also be performed again prior to Go Live. There is nothing worse than sequestering your entire business team for days of testing – then to watch everyone sitting idly because the someone realized the data is not right and the planned test scripts cannot be performed. A well-constructed formal Data Validation Plan is the “secret sauce” that engages the business in a methodical way to spot those unexpected data issues so the project team can take the appropriate action before it’s too late.
   

 
I wish you and your project team a safe journey. But be on the lookout for these warning signs, and if you see any, make course corrections quickly.