ABSTRACTHeader Information
- Work-Tool Code: DQ01WT01
- Product-Code: BIPM-DQPACK02
- Total number of controls and Methods: 65
- Help File: 6
- Relevant FAQ: 3
- Relevant Tips: 3
- Number of Main working-sheets: 1
List of Parameter Groups
- Interface
- Input form
- Batch-Processing
- Business Partner
- Business Process
- Data Model
- Domain and Data Standards
- Business Rules
Overall Usage Guide
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.
Relevant FAQs:
- We have major systems project in progress and are in design phase. Should we bring up the need for apply DQ assurance methodology? It will be too late to change or add new requirement at this point of time.
- How to handle the DQ assurance of existing objects getting changed by a system initiative? There are many interfaces getting changed by a new systems initiative. We did not fund ourselves for ensuring DQ assurance in pre-existing objects. How should we handle this?
- Can we rate the design and test phases on exception level? In other words, can we leave the rating blank if the design and test phase are complying with what was specified in the analyze phase?
Relevant TIPs:
- Building organization readiness for DQ assurance in a project
- Clarifying the roles and responsibilities for IT vs. Business in DQ assurance specifications
- Piggy-Backing the Initiative level DQ assurance assessment on analyze and design efforts.
|