By Michael Stiffler, Strategic Consultant, Data Governance, Harte-HanksTrillium Software
One activity that may help create a credible and successful Data Governance program – and achieve early executive buy-in – is embedding Data Governance policies and processes into your corporate infrastructure. This allows for seamless integration of Data Governance into existing processes your company is already relying on.
An example of where you can do this is in your software/system development life cycle (SDLC). Now, of course, if you don’t take this approach, violations of these data governance policies will be seen downstream after the project's completion (ideally earlier if you have robust test and development cycles). But to keep rework to a minimum, be proactive about Data Governance and embed your DG processes into the development lifecycle in the planning stages and through the formal project management organization.
Gathering business metadata, documentation, approvals, accountable parties, and data owners is usually much easier when you incorporate these elements up front, than after the completion of the project. That makes sense, right?
And creating new processes for data quality mitigation or establishing escalation processes is less efficient when it needs to done as a fire drill on the back end.
Additionally, Data Governance will be a part of the project timeline and you won't have to reset expectations or risk losing resources (e.g., subject matter experts) that are not already allocated and approved for the Data Governance effort.
Among other things, Data Governance should help bridge the gap between IT and the business. As part of this partnership, these two organizations would have already agreed to follow a standard process for application/system/database development (from collecting requirements to production release), so Data Governance policies will fit right in.
Piggy-backing off existing lifecycle project agreements and embedding Data Governance processes into your SDLC is a logical extension and should make enforcement of Data Governance policies a little easier.
Have you done this before? How did it work out for you?

I agree with you, but there is often resistance from the IT folk on this as they think it can and should just be about technology. How do you overcome this?
Posted by: Adrian Bennett | 08/19/2011 at 11:13 PM
Thanks for your comment. There is actually a bright side to that problem! I have often seen the reverse -- where IT doesn't want to own the issues and they won't make the investment in technology to fix data quality issues. A mature data governance program should have a good mix of data quality technology included anyway (for executing data profiling, data monitoring, standardization, cleansing, etc.). Data governance just puts formal business processes around it.
Now, to answer your question. This is where tactful conversations come into play. IT should understand that the business folks "own" the data. For example, only they understand the business rules and requirements for collecting and using the data; only they can answer questions around data standards, what metrics and measurements should be tracked, etc. Additionally, the business SMEs can provide business definitions and assist with other documentation that will help streamline development and issue resolution processes. This partnership will help minimize the time it takes IT to react to certain data (quality) issues.
For example, I have often seen fire drills where IT has to track down the data owner, a business definition or requirement, or get approvals. Having all of this up front can save hours and sometimes days when IT is on the hook for fixing an issue.
What's the old adage, an ounce of prevention is worth a pound of cure? :)
Posted by: Mike Stiffler | 08/23/2011 at 12:11 PM