Root-cause analysis is a core technique of all data quality improvement initiatives. You can’t improve a situation unless you know what is causing it to happen in the first place.

There are many different techniques for root-cause analysis. Recently I discussed the 5 Why’s technique and how to improve it – but of course one of the most popular root-cause tools is the Fishbone or Ishikawa diagram, which I noticed fellow blogger Carol Newcomb covered in her recent Data governance primer post.

Depending on the industry, defects are assigned across the Fishbone diagram to several different causes. For example, in manufacturing (where the tool originates from), the following categories are popular:

• Machine (technology)

• Method (process)

• Material (includes raw material, consumables and information)

• Manpower (physical work) or mind power (brain work): kaizens, suggestions

• Measurement (inspection)

• Mother Nature (environment)

Other M’s commonly used include management and maintenance, so you can see the manufacturing influence coming through.

One M that I think is missing and deserves to be included is motivation, and I think it's critical enough to break this out of the traditional manpower category.

When analysing data, it’s often easy to find defects and attribute them to data entry finger flubs or incomplete information being entered. However, if we’re looking to go deeper with our root-cause analysis, you need to get into the motivations that lead to the mistake being created.

For example, I’ve often witnessed field engineers posting poor-quality information after site installations or maintenance visits. But what is their motivation if they are rewarded for the speed of their service? Digging deeper invariably surfaces hidden motivations that no amount of technology and process can reverse.

It’s not just field workers who have these motivational dilemmas. As a DBA, your primary motivation may be to guarantee the performance of overnight batch jobs. As a result, you may elect to switch off referential integrity in order to guarantee faster load rates. Decisions like these can result in defects occurring over time, and they stem from motivations that are often well-founded but conflicting to your goal of faultless data.

So the next time you’re asked to perform a data quality assessment or improvement exercise, add an extra dimension to your root-cause analysis process. Get into the minds of your knowledge workers and indeed coders, architects, DBAs, stakeholders – anyone who impacts the quality of information in your control. Document their motivations and record any conflicts that can be tracked and improved.

What do you think? Does it make sense to create a new root-cause category? Welcome your views.