Data Quality Assurance Method Level Tracking- Project Based

NOTE- This template is part of the paid Data Quality Package- the most comprehensive online data quality management tool-Kit. This page provides a sample view of the usage of this template. For Buying this template and the entire Data Quality Package, please Click Here

Data Quality assurance methods have both flavors of being a business requirement (the business checks before and after one runs a batch) as well as the technology design (triggers, referential integrity). Refer to Data Quality Assurance for the list of methods. DQ Assurance Method Level Tracking is applicable for any System related initiative with an IT component. We have not covered the data quality assurance methods for purely non-IT initiatives. Please go to end of page to download the template

Purpose of Data quality Method-Level Tracking tool-

DQ Assurance Method Level Tracking tool is a conscience-keeper to have an informed understanding of the extent to which the Quality Assurance Methods are applied. Apart from being conscience-keeper, it also is used as a formal document for doing root-cause analysis, audit review and for future changes in the systems or processes.

DQ Assurance Method Level Tracking is used for each different system ( and associated business processes) which is involved in a given project.

When is Data Quality Method-Level Tracking tool is used?

This checklist is used at Project/Initiative Level

• Project Analyze phase – The tracking sheet should be filled-up during the detailed business requirements (functional specifications) and modeling Phase. Include this activity as part of the work break down structure of Analyze phase.
• Project Design Phase – Same as above, but to be applied in the design phase. This will include more of file interface, screen deisgn, batch controls etc.
• Project Implementation Phase – This is used for final sign-off on the project.

NOTE- This tool does point to the factors you should take into account while doing system stability and quality assessment**. However, this is not the tool to be used for this purpose. This tool needs to be used only when you are going for a new IT initiative, involving existing or totally new systems and processes.

How is Data Quality Method-Level Tracking tool is used?

Apart from sign-off, this checklist should be referred to, while the functional specing (both part of Analyze phase), technical designinig and testing & implementation is in progress.

Typically the output of this sheet should be jointly signed off by the project manager as well as the data steward** or Head of Information management (Refer Data Quality Program Deliverable- Data Quality Organization ).

This is the broad flow of usage:

• As your functional specs come near completion, the business and IT analysts, will fill-up this checklist and attached it along with the functional specs document as an appendix. This output gets signed-off by the project owner, data steward (if the role exists in the organization) or IT owner and business owner.
• As your Technical and Business Process design (the design phase of a project is not only IT design but also designing the business processes around the IT systems) comes near completion, this sheet will be filled-up, and signed off by the project owner, Data Steward (if the role exists) or IT owner and business owner.
• Once your testing is complete and you are looking for go-ahead for implementation- This tracking tool will be filled-up depicting if the controls are signed-off and the status of quality assurance methods, finally ready for implementation, are acceptable.

Linked Practice Tools

The Data Quality Method Level Tracking is closely linked with Data Quality Assurance Specifications and Design Template. The DQ Assurance Specs and Design template, is part of your function, design and deployment documents, to define the quality assurance mechanism for each object in the system(s) and the associated business processes linked to the initiative.

Tips for effective usage

• DQ Assurance Method Level Tracking provides the master list of all the QA methods which you can deploy in an IT enabled initiative. We also enourage you to assign a code control number against each type of control. This will help you to link with the functional and technical specs, where you are designing these controls. For example, if in your functional specs, you have a screen layout, you would like to have the input controls** defined for that screen. As you define these controls, you will be referrinig the control-code. This will help you maintain the audit on which control you are using where.

• You don't have to implement all the controls at every point. Every quality assurance method has a business-case. As you fill-up this checklist, you should list out in comments on the business-case aspects of the control.

• This list is not only for internal reasons, but can be an extremely good vehicle for internal and external audit. It can also be used for root cause investigation in case of a data quality issue. This can be among the first set of reference docs as you do DQ gaps root cause analysis.

• You need to be quite extensive in your comments. The checklist provides the flags of Done/Not-Done/Partially Done/Not Applicable. These tags are indicative. The comments section will be mainly focusing on the areas which are not done or partially done and why. The reasons could be the business

Help Guide For using this work-tool

This is the explanation of how to use this template. The explanation is provided for each heading in columns and rows, in the main page in the downloaded template file.

Control Code

This Code is essentially the master code you apply to a given control or quality assurance method. There is a separate list of Data Quality Assurance Methods and Controls. This code will be picked from the list.

System Code

This the code of the system for which the checklist is getting populated. There can be multiple systems involved in an initiative. The reason for filling this sheet for each system is because there can be different owners (both IT and Business) for different systems. Hopefully you have a list of system owners and data custodians.

You can copy and paste the DQ Main Template Sheet, and create new worksheets for other system.

RATING

You can assign the rating in terms of overall level of adherence to the DQ assurance parameter. This rating can be a combination of the aggregation of the level of adherence for each system/process object and a judgment. We would not recommend a strict algorithm for calculating rating. The rating serves the purpose of understanding the overall visual of your level of Data Quality preparedness.

We have applied a conditional formatting, whereby, the tool will give Red (1-4) Amber (5-7) and Green (8-10) color, depending upon the rating score you enters. Rating can be given at three levels- Overall System Level, Method Group Level (like Interface controls, Input controls etc.) and for each line item.

COMMENTS

Whereas Rating gives an overall visual of how well we are doing on DQ assurance, the comments provide the high level description of what is 'exceptional or missing' in case your rating is in amber or red. The comments (like rating) can be at an overall system level, Method Group Level (like Interface controls, Input controls...) and for each line item. The comments is again a kind of summary of the detail you have in 'Object Level Data Quality Assurance Tracking- For projects'

Analyze Rating

This rating can be given for most of the parameters, apart from the ones which are pure design level criteria, like Batch processing failure response. However, most of the parameters will be equally applicable for functional specifications phase. Typically, rating of analyze phase will always be higher of equal to the rating at design and testing phase. In other words, if you do not spec it out, it will not be designed and deployed. In some cases though, you may have a rethink on a control, and you include it during the design phase. In this case rating in the design phase will be higher compared to the analyze phase.

Analyze Comments

Typically you would like to include all data quality assurance methods in the functional specs. However, the reason many of them get excluded is that time and effort needed to spec, design and deploy them makes the business case infeasible. In other words, every business owner wants a robust system, as long as it does not have a negative impact on the business-case. As you provide comments, you should ideally mention on if a given control is not included in the functional spec, what's the reason behind it.

Design Rating

This rating can be given for all parameters. When we say design, it includes both the system IT design and business process design, for the processes which are linked to the system. The design rating will be same as that of analyze rating, if everything is fine. It may be lower than analyze rating, if you exclude or down-scale a control agreed during the analyze phase. This may happen because of revised estimates or linkage with some other factors, which are not in your control.

Design Comments

Typically you would like to include all data quality assurance methods in the functional specs. However, the reason many of them get excluded is that time and effort needed to spec, design and deploy them makes the business case infeasible. In other words, every business owner wants a robust system, as long as it does not have a negative impact on the business-case. As you provide comments, you should ideally mention on if a given control is not included in the functional spec, what's the reason behind it. The rating in design phase can be higher than analyze phase in the situation where you reconsider including some controls which you did not scope in the analyze phase.

Deployment Rating

All parameters can be rated in the deployment phase. The rating score should be ideally same or below the design phase, as you cannot create any new controls or QA methods in the testing and deployment stage. The reason rating can be lower compared to the design or analyze phase will on if you find the given control is not successfully tested, and you may propose to go ahead without that line item.

Deployment Comments

Deployment comments should refer to the reasons why the rating score is lower compared to the design phase rating score.

Project Life-Cycle Comments

These are the comments which provide the view across the entire project life cycle.

Data Quality Assurance and Control Parameters:

These are the parameters, again which you will be assessing the state of Data Quality mechanisms in your systems and associated processes. You can click on this cell to go to our knowledgebase to understand all the listed parameters.

Interface Data Transmission Control:

Click on the cell to go to the page detailing all the listed data transmission controls. As you fill this work-sheet, take look at all possible interfaces, you plan to implement in this initiative, and identify the DQ assurance in data transmission. If you are using DQ Assurance Specing and Design tool, it will help. Yon can click on the cell to go to the knowledge-base related to this subject.

Input Controls

Click on the cell to go to the page detailing all the listed Input controls. As you fill this work-sheet, take a look at all possible screens and user interfaces, you plan to implement in this initiative, and identify the DQ assurance in all of them. If you are using DQ Assurance Specing and Design Template, it will help. Yon can click on the cell to go to the knowledge-base related to this subject.

Generally, many inputs controls are reusable. For example, you can use the same location drop down select field for all screens where you are entering location. Similarly you can use the same customer-Vendor data searching and matching program on various screens, where you are entering any customer-vendor details.

Data Domain and Data Standards Definition

Click on the cell to go to the page detailing all the listed items within Data Domain and Data Standards. Having Data Domains and Data Standards
, and adhering to them are two different subjects. The ideal scenario for an organization is to have universal data domains (like PIN Codes, Locations...) and Standards (like customer ID format), or at least the initiative specific domain and standards (which is not ideal but better than having nothing). All the items listed in this group, will be rated on the basis of being defined for the initiative (and not necessarily at the enterprise level).

Data Model

Click on the cell to go to the page detailing all the listed items within Data Model. Having Data models, and adhering to them are two different subjects. The ideal scenario for an organization is to have universal data models (like customer data model), or at least the initiative specific Data models OR Entity-Relationship Diagrams (which is not ideal but better than having nothing). All the individual items listed in this group, will be rated on the basis of being defined for the initiative (and not necessarily at the enterprise level).

Business Rules

Click on the cell to go to the page detailing all the listed items within Business Rules. Business Rules is a little open subject and sometimes it becomes difficult to ascertain if you have all the business rules defined to ensure data quality. Many of these business rules actually come out of Data Model (or Entity Relationship Diagram).

Batch Processing Controls

Click on the cell to go to the page detailing all the listed items within Batch Processing Controls. Contrary to conventional understanding, most of the batch-processing checks and controls are part of the functional specs, during analyze phase. In functional specs, you have the conditions defined for initiating and completing transactions. Some of these conditions are part of the OLTP transaction logic and some of them are included in the pre-run and post-run checks in the batch processing.

Business Process Controls

Click on the cell to go to the page detailing all the listed items within Business process controls. Business processes here are essentially related to the processes linked to the IT system. It does not include the pure manual business processes not linked with the system.

Business Partner Controls

Click on the cell to go to the page detailing all the listed items within Business Partner controls. Business partner controls are tricky as they rely upon the controls deployed by the business partners.

Overall Analyze Comments

You can enter the overall comments on the state of the DQ mechanisms, as speced in the Analyze (functional specifications) phase. This will be a good reference for the signatories to review before they sign-off a specific phase-exit.

Overall Design Comments

You can enter the overall comments on the state of the DQ mechanism as speced in the design (technical design and business process design) phase. This will be a good reference for the signatories to review before they sign-off a specific phase-exit.

Overall Deployment Comments

You can enter the overall comments on the state of the DQ mechanism as speced in the deployment phase. This will be a good reference for the signatories to review before they sign-off a specific phase-exit.