1.4.7   Applying the ADKAR Assessment Results

Identify the first area that scored 3 or below. This is your “barrier point” and what needs to be addressed first. By addressing the first area with a low score, you will positively impact all the goals that follow.

1.4.8   Actionable Steps

If awareness is needed: discuss and explore the reasons and benefits for this change. Discuss the risks of not changing and why the change needs to happen now.

If more desire is needed: to move this person forward you must understand and address their inherent desire to change (which may stem from negative or positive consequences). These motivating factors have to be great enough to overcome the individual’s personal threshold to resisting the change.

If more knowledge is needed: avoid dwelling on reasons for change and motivating factors, as this is unnecessary and could be discouraging. Focus now on education and training for the skills and behaviours necessary to move forward.

If more ability is needed: first, time is needed to develop new abilities and behaviours, and this person simply may need more time to develop new skills with proficiency. Second, ongoing coaching and support could be required - consider outside intervention, continued support and mentoring.

If more reinforcement is needed: investigate if the necessary elements are present to keep the person from reverting to old behaviours. Address the incentives or consequences for not continuing to act in the new way and re-visit the knowledge and ability milestones. It may be that more training and education is needed as processes develop and evolve.

1.5    TO CONCLUDE

The ADKAR Model is an essential tool for leaders and change professionals. It is effective, easy to grasp and can be applied in a wide variety of organizational settings.

Using the ADKAR model will help you to plan effectively for a new change and also help diagnose where a current change is failing, so that you can take corrective action. Each step of the model outlines the individual’s successful journey through change and provides an outcome orientation for your change management activities. For example, you will no longer develop a communications plan for the sake of having a communications plan; now you will develop a communications plan to specifically drive awareness of the need for the change. If you are ready to change, either personally or professionally, this results-oriented approach will increase your change success.  

For a more in-depth study of the ADKAR Model, we highly recommend the ADKAR eBook below, where all examples, applications and explanations are explored in more detail. The ADKAR exercise and table are also included.

104 Laws of Project Management

1. "A badly planned project will take three times longer than expected - a well planned project only twice as long as expected."
2. "A change freeze is like the abominable snowman: it is a myth and would anyway melt when heat is applied."
3. "A little risk management saves a lot of fan cleaning."
4. "A minute saved at the start is just as effective as one saved at the end."
5. "A problem shared is a buck passed."
6. "A project ain't over until the fat cheque is cashed."
7. "A project gets a year late one day at a time."
8. "A project is one small step for the project sponsor, one giant leap for the project manager."
9. "A two year project will take three years, a three year project will never finish "
10. "A user is somebody who tells you what they want the day you give them what they asked for."
11. "A user will tell you anything you ask about, but nothing more."
12. "A verbal contract isn't worth the paper it's written on."
13. "Activity is not achievement."
14. "All project managers face problems on Monday mornings - good project managers are working on next Monday's problems."
15. "Any project can be estimated accurately (once it's completed)."
16. "Anything that can be changed will be changed until there is no time left to change anything."
17. "At the heart of every large project is a small project trying to get out."
18. "Estimators do it in groups - bottom up and top down."
19. "Everyone asks for a strong project manager - when they get him they don't want him."
20. "Fast - cheap - good: you can have any two."
21. "Feather and down are padding - changes and contingencies will be real events."
22. "Finely chopped cabbage in mayonnaise - Coleslaw."
23. "For a project manager overruns are as certain as death and taxes."
24. "Furious activity does not necessarily equate to progress and is no substitute for understanding."
25. "Good control reveals problems early - which only means you'll have longer to worry about them."
26. "Good estimators aren't modest: if it's huge they say so."
27. "Good project management is not so much knowing what to do and when, as knowing what excuses to give and when."
28. "Good project managers admit mistakes: that's why you so rarely meet a good project manager."
29. "Good project managers know when not to manage a project."
30. "I know that you believe that you understand what you think I said but I am not sure you realise that what you heard is not what I meant."
31. "If an IT project works the first time, it is wrong."
32. "If at first you don't succeed, remove all evidence you ever tried."
33. "If everything is going exactly to plan, something somewhere is going massively wrong."
34. "If it can't possibly go wrong, it will - O'Malley's corollary to Murphy's law."
35. "If it can go wrong it will - Murphy's law."
36. "If it happens once it's ignorance, if it happens twice it's neglect, if it happens three times it's policy."
37. "If it looks like a duck, walks like a duck and quacks like a duck, it probably is a duck."
38. "If it wasn't for the 'last minute', nothing would get done."
39. "If project content is allowed to change freely the rate of change will exceed the rate of progress."
40. "If there is a 50% chance of something going wrong then 9 times out of 10 it will."
41. "If there is anything to do, do it! "
42. "If there were no problem people there'd be no need for people who solve problems."
43. "If you're 6 months late on a milestone due next week but really believe you can make it, you're a project manager."
44. "If you can interpret project status data in several different ways, only the most painful interpretation will be correct."
45. "If you can keep your head while all about you are losing theirs, you haven't understood the plan."
46. "If you don't attack the risks, the risks will attack you."
47. "If you don't know how to do a task, start it, then ten people who know less than you will tell you how to do it."
48. "If you don't plan, it doesn't work. If you do plan, it doesn't work either. Why plan!"
49. "If you don't stand for something, you'll fall for anything."
50. "If you don’t know where you’re going, any road will take you there."
51. "If you fail to plan you are planning to fail."
52. "If you have time to do it over again, you'll never get away with doing it right the first time."
53. "It's not the hours that count, it's what you do in those hours."
54. "It takes one woman nine months to have a baby. It cannot be done in one month by impregnating nine women (although it is more fun trying)."
55. "It will go wrong in the worst possible way - Sod's law."
56. "Managing IT people is like herding cats."
57. "Metrics are learned men's excuses."
58. "Murphy, O'Malley, Sod and Parkinson are alive and well - and working on your project."
59. "Never underestimate the ability of senior management to buy a bad idea and fail to buy a good idea."
60. "No plan ever survived contact with the enemy."
61. "No project has ever finished on time, within budget, to requirement - yours won't be the first to."
62. "Nothing is impossible for the person who doesn't have to do it."
63. "Of several possible interpretations of a communication, the least convenient is the correct one."
64. "Overtime is a figment of the naïve project manager's imagination."
65. "People under pressure do not think faster."
66. "Planning is an unnatural process, doing something is much more fun."
67. "Planning without action is futile, action without planning is fatal."
68. "Powerful project managers don't solve problems, they get rid of them."
69. "Projects happen in two ways: a) Planned and then executed or b) Executed, stopped, planned and then executed."
70. "Quantitative project management is for predicting cost and schedule overruns well in advance."
71. "Some projects finish on time in spite of project management best practices."
72. "Some things that don't count are counted, many things that count aren't counted."
73. "The bitterness of poor quality last long after the sweetness of making a date is forgotten."
74. "The conditions attached to a promise are forgotten, only the promise is remembered."
75. "The first 90% of a project takes 90% of the time the last 10% takes the other 90%."
76. "The first myth of management is that it exists."
77. "The more desperate the situation the more optimistic the situatee."
78. "The more ridiculous the deadline the more money will be wasted trying to meet it."
79. "The more you plan the luckier you get. "
80. "The most successful project managers have perfected the skill of being comfortable being uncomfortable."
81. "The most valuable and least used phrase in a project manager's vocabulary is "I don't know"."
82. "The most valuable and least used word in a project manager's vocabulary is "NO"."
83. "The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression."
84. "The person who says it will take the longest and cost the most is the only one with a clue how to do the job."
85. "The project would not have been started if the truth had been told about the cost and timescale."
86. "The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times."
87. "The sooner you begin coding the later you finish."
88. "The sooner you get behind schedule, the more time you have to make it up."
89. "There's never enough time to do it right first time but there's always enough time to go back and do it again."
90. "There are no good project managers - only lucky ones."
91. "There is no such thing as scope creep, only scope gallop."
92. "There is such a thing as an unrealistic timescale."
93. "To estimate a project, work out how long it would take one person to do it then multiply that by the number of people on the project."
94. "Too few people on a project can't solve the problems - too many create more problems than they solve."
95. "Users get the systems they deserve."
96. "Warning: dates in the calendar are closer than you think."
97. "What is not on paper has not been said."
98. "What you don't know hurts you."
99. "When all's said and done a lot more is said than done."
100. "When the weight of the project paperwork equals the weight of the project itself, the project can be considered complete."
101. "Work expands to fill the time available for its completion - Parkinson's law."
102. "You can build a reputation on what you're going to do."
103. "You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it."
104. Project management with lot of documents is not project management

 

1                 Introduction

1.1        Purpose

The purpose of this document is to define the Information Quality Metrics for the Information Quality Management Framework. This is a sub component of the overall Information Quality Management Framework being implemented through the  Performance Management Program .

This document provides the detail of each of the specific components that need to be defined developed and implemented to support the initial adoption of better Information Quality Management in and that are essential to the Program’s Project Delivery Stage. In most cases specific documentation will be developed for each component.

Articulation of the overall vision, strategy, program scope and critical success factors as well as the overall program governance is covered in the Program Management Plan.

1.2        Background

An organisation’s approach to Information Management is critical to its success. Information Management provides the framework that the business needs in order to maintain, verify, and take control of the flow of data from source to destination, and to plan it’s archival or deprecation.

Implementing Information Quality Management provides a measurable and confidence in reporting and information analysis as the final output; the Information in the report can be trusted and tracked. If necessary, a data lineage can be reported on to show the information’s source and any transformations that have occurred during its journey to the final user.

The Information Management Methodology describes the framework and approach to improving how information is managed, measured and improved upon across . The methodology consists of components such as principles, policies, practices, tools, processes and procedures, and governance, that work together to manage the information throughout its lifecycle, including maintenance, validation and archival or disposal.

The methodology also involves the application of management techniques to collect information, communicate it within and outside the organisation, and process it to enable managers to make quicker and better decisions.

The Information Management Methodology is the vehicle for addressing Information Quality issues and establishing the associated information governance structures and processes. Quality issues are measures against the metric described in this document.

1.3        Objectives

The Information Quality Management Framework document will provide the subcomponent of the Information Quality Management Framework. It will describe the definitions of metrics. This document is a self contained subcomponent of the overall Quality framework.

2                 Information Quality Metrics

Data Governance Metrics provide the information quality objectives that the organisation plans to achieve. Just like other business performance measures, metrics should be managed and tracked at the executive level. Metrics are created by either executives or data stewards with input from data analysts. Each KDE is measured against the defined metric category through the appropriate measurement technique.

There are different types of Qualitative Metric categories that can be measured in varying fashions: Accuracy, Integrity, Consistency, Completeness, Validity, Accessibility, and Timeliness. Data Governance Metrics

This task defines each of these categories and the measurement techniques and processes that will be used for measuring each KDE. Sometimes, less tangible metrics are also assessed. A rating scale should be defined for metrics at an aggregate level that is supported by the detail of the assessment.

Output / Artefacts:

·        Definition of Metric Categories and Measurement Techniques

·        Current-State Metrics on KDEs

·        Target Metrics on KDEs

Typically, organisations do not only measure along quantitative dimensions, but also include softer/intangible dimensions to justify their investment and measure success. Defining data quality KPIs requires interplay of organisational support, governance and accountability, processes, policies and standards, as well as an overall support (either automatically or by analysis from members of the data governance team) by a set of tools. The following diagram outlines an approach to measuring data quality:

2.1        Detailed Information Quality Metrics

How are Data Governance Metrics Measured?
Metric Category	Description	How is Metric Measured?
Accuracy	Does the data accurately represent reality or a verifiable source?	Audit
Integrity	Do broken links exist between data that should be related?	Profiling / Business Rules
Consistency	Is there a single representation of data?	Profiling / Business Rules
Completeness	Is any key information missing?	Profiling / Business Rules
Validity	Is the data stored in acceptable format and contain valid values?	Profiling / Business Rules
Accessibility	Is the data easily accessible, understandable, and used consistently?	Survey
Timeliness	Is information recorded and made available to systems as rapidly as is required?	Survey

2.1.1    Accuracy/Correctness

Description:

·        The degree of agreement between a data value (or set of values) and a source assumed to be correct. The source may be a reference set obtained by comparison to “real world” data, or by reference to a data set on another system or file that is deemed “correct”.

Typical issues uncovered during assessment:

·        It is expected that some names and addresses will be spelt incorrectly, or not an accurate representation of the real party, or address. Other free form text, including customer description information may not be correctly representing the party.

·        Effectiveness of profiling to assess this area:

·        Accuracy is very difficult to assess without verifying customer details directly with the customer, or using a “correct” 3rd party data source. Where a reference data set is available, e.g. a list of postcodes or addresses, this may be assessed; otherwise the source system data is assumed to be accurate.

2.1.2    Completeness

Description:

·        The degree that the full values are present in the attributes that require them, and the degree that the attributes cover the user data requirements.

Typical issues uncovered during assessment:

·        Free text fields not completed (E.g. Name, address, phone numbers, types, descriptions, and null values). Target mandatory fields not populated, or present in the source system extract file. The source systems may not have all the attributes required to load the target systems.

·        Effectiveness of profiling to assess this area:

·        The completeness of the field values is tested as part of the specific TBA tests. The completeness of the attributes to satisfy the user requirements are assessed in the source to target mapping documents that highlight where a target attribute cannot be populated because a source field not available

2.1.3    Timeliness / Currency

Description:

·        Currency measures how up-to-date the data is, and whether the data required can be provided by the required time.

Typical issues uncovered during assessment:

·        The source extracts may not be provided by the required time. Product and type codes that change over time may cause products, or types assigned before a particular date for one product, or type, and those assigned after the cut-over date are a slightly different product with the same code or now have a different type.

·        Effectiveness of profiling to assess this area:

·        The source system product codes are expected to be unchanged over the product life. If these assumptions do not hold the change in product code is handled during the transformation of source data in the target data acquisition.

·        Changes to customer type, product types, and other codes will be treated the same way as product codes. Delays in providing the source system extracts by the specified time are identified as part of the general project reporting.

2.1.4    Consistency / Uniqueness (No Duplicates, Integrity)

Description:

·        Consistency is the extent that there is a single representation of data. Consistency also includes the extent that data is duplicated within a system, e.g. customer duplicates.

·        The ability to establish the uniqueness of a data record (and data key values).

Typical issues uncovered during assessment:

·        Duplicate customer records

·        Effectiveness of profiling to assess this area

·        Determining whether there are customer duplicates in large volume data sets require specialist tools.

·        De-duplication also requires a dedicated data quality improvement project that includes the appropriate governance, and sponsorship as well as appropriate tools to establish and implement the de-duplication.

2.1.5    Validity

Description:

·        The data is stored in an acceptable format, and is within a reasonable range of possible values.

·        Target enforced formats, lengths, and data types not implemented in the source systems. (E.g. Date YYYY-MM-DD is stored as a character in most host systems and if these fields contain other characters they cannot be transformed into the target date format)

Typical issues uncovered during assessment:

·        Target enforced formats, lengths, and data types not implemented in the source systems. (E.g. Date YYYY-MM-DD is stored as a character in most host systems and if these fields contain other characters they cannot be transformed into the target date format).

·        Target codes, and types may not map 1-to-1 to the source system codes, and types. Values for some attributes are not within an acceptable range.

·        Effectiveness of profiling to assess this area

·        It is generally not practical to check all the values in every attribute loaded are the correct type, length, and format. The most important data types to assess are date, and numeric fields.

·        Check, and convert where possible source system date to the YYY-MM-DD standard target format.

·        Check the format of identification numbers.

·        Range of important balance, rate fields. This will only be an atomic value checks, it will not net accounts, and check the range.

·        Compound attribute tests: Check the value of one attribute that is dependant on another attribute.

2.1.6    Accessibility

Description:

·        Ability for users to extract the existing data they require. Users must not have different interpretations of the same data. Ability for users to extract the existing data they require. Users must not have different interpretations of the same data.

Typical issues uncovered during assessment:

·        The meaning of each file attribute, and the interrelationship between attributes, and files is difficult to determine. This requires specific product system, and business knowledge.

·        This may cause errors in the mapping of source fields, to target fields.

·        The layout, and extract process documentation may not match the actual source system files delivered.

·        Effectiveness of profiling to assess this area:

·        This is a manual check of source system data, and metadata availability.

·        If the meta-data does not match the actual file an issue is raised.

The relevant subject matter experts will be consulted to confirm, or explain the definition of ambiguous or conflicting attributes.

3                 Data Profiling

Possible outcomes for information quality enhancement:

1.        Do nothing (measure the Quality problem

2.        Correct the information in transit (ETL data correction)

3.        Root Cause Analysis of Data Governance Issues

Preventing Data quality issues involves analysing those process activities or application automation that prevents Data quality issues from occurring in the first place. Root Cause Analysis of Data Governance Issues is concerned with correcting root cause issues as opposed to addressing the symptoms.

Outputs:

·        Data Governance Issues related to Source System Edits, Business Process, and Technology Architecture.

·        Recommended Changes for Improved Data Governance

3.1        Objectives of Data Profiling

·        Identify data quality issues - measurements are taken against a number of dimensions, to help identify issues at the individual attribute level, at the level table and between tables.

·        Capture metadata as a by-product of the process – Metadata is the key to the success of subsequent phases of the data load including the ongoing use and maintenance of the data. Useful metadata is identified as part of the data profiling exercise and the tool-based approach will ensure it is captured in a reusable format.

·        Identify business rules – The next step is to perform the data mapping. Data profiling will assist in gaining an understanding of the data held in the system and in identifying business rules for handling the data. This will feed into the data mapping exercise.

·        To assess the ‘fitness for purpose’ of the source system data to satisfy the business requirements. This assessment is often done in the context of a Data Warehouse, CRM, or ERP system initiative. Therefore, the focus is on gaining a very detailed understanding of the source data that will feed these target systems, to ensure that the quality level is sufficient to meet the requirements of the target system.

This section is meant to provide guidelines as to the tests that are commonly used and the approach taken to measure data quality. Each project should consider these to be a starting point only and should ensure that the specific tests that will uncover greatest value for a client are uncovered as part of the discovery process for this client.

Key Output / Artefacts:

·        Data Quality Report (per Source Systems)

·        Definition of Mapping Rules and Business Rules

3.2        Different Types of Profiling

Data sources are profiled in multiple dimensions: down columns (Column Profiling); across rows (Table Profiling); and across tables (Multi-Table Profiling). The output from Data Profiling can then be used in a number of fashions, including data cleansing and mapping to a target environment.

 

3.2.1    Column Profiling

Column profiling typically examines the data found in a single column/field in either a table or a flat file. This analysis can either (1) examine the actual values found in the column (e.g. produce a complete frequency report listing each and every value found), (2) look for the various “data patterns” for the values in the column or (3) discover the underlying “parsed patterns” that might exist within more complex, free-form columns. Assessments are typically conducted to verify the validity/uniqueness, accuracy and completeness; column profiling can help answer the following questions:

·        What do the fields mean?

·        Which ones are of interest to the project?

·        What is the quality of data in each field?

·        And, given this, is the data of sufficient quality to load to into the target information environment?

Analysis on complex fields such as names, addresses, and contact information can be done to determine the patterns and consistency of the data. This provides information on the consistency of the values in a standard format and if the format is one that has been used already across similar fields on other tables within the database. From a vendor perspective, separate tools may be used to profile simple fields (ones that do not require parsing) as opposed to complex fields.

3.2.2    Table Profiling

Table Analysis is used to determine the key information and also relationship and dependency patterns between the data in each field within the table. It is done across every field within each table in the source system. Table Analysis is important as there are some situations where it is absolutely essential to examine values in two or more columns. A blank value in Column A might be acceptable if there is a valid value in Column B, but unacceptable if Column B is also blank. Similarly, a valid value in Column A (e.g., product code “HL”) and a valid value in Column B (e.g., sub-product code “521”) might be an invalid code combination. In such situations you must look at value combinations across columns rather than just examine values within a single column. A tools-based approach is undoubtedly the best choice for examining these cross-column or “table based” dependencies.

3.2.3    Multi-Table Profiling

Multi-Table Analysis looks for relationships among columns existing in different tables, rather than just within a single table. Multi-Table profiling shows the relationships between tables using key fields as links to bridge the multiple tables. The aim is to analyse and determine the existence of referential integrity issues between each table analysed, e.g. orphans and clients without address and contact information. If the profiling analysis reveals two columns in different tables share the same set of values and one is not a foreign key and the other a primary key, than redundant data exists between the two tables. For example, an employee table and an employee demographics table might both contain a “home phone number” column and the same values within these columns. Thus, an employee’s home phone number might be stored redundantly in two separate tables.

3.3        The Iterative Profiling Process

It is important to note that there is an iterative approach to profiling within each of the analysis steps below. Each step involves:

·        Running the analysis within the appropriate Vendor Tool

·        Analysing the results of each analysis

·        Verify the results with the Source System SME

·        Documenting the results (both in deliverables and within the profiling tools)

·        Plan further analysis based on results

The data investigation process should verify what the source system owners say about the data against the actual data; it should also verify what the data says against what the source system owners say.

This process is iterative – for example, a source system owner may say that all customer names must have a full first name and full surname. However, when this rule is checked against the data, this shows that 10% of the records have only a first initial. In this case, this must be discussed with the source system owner. This type of anomaly may be explained by a business rule that was applied to new data that was not applied to historical data. Further analysis is performed in this case to verify that all anomalous records were created before the expected data. Data Re-Engineering also follows and iterative process for standardize, correct, match and enrich data.

3.4        Typical Investigations Performed

3.4.1    Column Profiling (Simple Fields)

Column Profiling of Simple Fields is most typically done to check for Completeness, Uniqueness and Validity. An example would be the Account Number field within the Client_Accounts table. The Account Number column is analysed for:

 

Column Profiling (Simple Fields)
Field	Test	Description
Account Number	Completeness	All records contain a non-zero value
	Uniqueness	All records contain a different account number
	Validity	Ensure all account numbers are numeric or follow the source systems account number structure

3.4.2    Column Profiling (Complex Fields)

Column Profiling of Complex Fields is most typically conducted to verify the validity/uniqueness, format accuracy and completeness. An example would be looking at Customer Records:

 

Column Profiling (Complex Fields)
Field	Test	Description
Multiple Fields	Completeness	As per Client Name. All the name fields should contain a title, firstname, and lastname. Not all person names contain middle names and suffixes such as Jnr etc.
	Uniqueness	Presence of Title at start of name Has a first name, and Has a last name
	Validity	No characters, i.e.: #,@% present in all the name fields.

3.4.3    Table Profiling

Table Profiling is most typically conducted to verify the validity/uniqueness, format accuracy and completeness. An example would be looking at Customer Records:

 

3.4.4    Multi-Table Profiling

Multi-Table Profiling is conducted to verify the validity/uniqueness and accuracy of the key fields to ensure referential integrity. An example would be to assess the Customer Table vs. a Customer Loan:

 

Customer Table
Field	Test	Description
Customer ID	Completeness	Is a unique value populated within this field to uniquely identify each customer record? If so is there a high population ratio on this field, i.e.: 100% populated.
	Uniqueness	Presence of a Primary Key or Foreign Key in relational databases. Are these keys unique to each record?
	Validity	Are these key fields populated with valid value, i.e.: unique values?
	Format	Are these values in a consistent format, i.e.: numeric or does it contain leading alphas etc.
Multi-Table Profiling Customer Table:
Field	Test	Description
Customer ID	Completeness	Is a unique value populated within this field to uniquely identify each customer record within the Customer table? If so is there a high population ratio on this field, i.e.: 100% populated.
	Uniqueness	Presence of a Primary Key or Foreign Key in relational databases. Are these keys unique to each record?
	Validity	Are these key fields populated with valid value, i.e.: unique values?
	Format	Are these values in a consistent format, i.e.: numeric or does it contain leading alphas etc.

 

Information Management Principles

 

 

 

 

Prepared by:	Marc Narder	Copy number:
Document Status: Dop:	Draft	Date:
Version:	Version 0.1	Deliverable No:

 

 

 

Document Name	Information Management Principles
Document Location
Document Owner	Marc Narder, Manager, Information Management

 

 

1                 Introduction

1.1        Purpose

The purpose of this document is to define the Information Quality Principles for the Information Quality Framework. This is a sub component of the overall Information Quality Management Framework., which is itself a subcomponent of the overall Information Quality Management Framework being implemented in the  Performance Management Program.

This document provides the detail of each of the specific components that need to be defined developed and implemented to support the initial adoption of better Information Quality Management in  and are essential to the program’s Project Delivery Stage. In most cases specific documentation will be delivered for each component.

Articulation of the overall vision, Strategy, program scope and critical success factors as well as the overall program governance is covered in the Program Management Plan.

1.2        Background

An organisation’s approach to Information Management is critical to its success. Information Management provides the framework that the business needs in order to maintain, verify and take control of the flow of data fro source to destination, and to plan it’s archival or deprecation.

Implementing Information Quality Management provides a measurable confidence in reporting and information analysis as the final output; the information in the report can be trusted and tracked. If necessary, a data lineage can be reported on to show the information’s source and any transformations that have occurred during its journey to the final user.

The information Quality Framework describes the framework and approach to improving how information is managed, measured and improved upon across . This framework consists of components such as principles, policies, practices, tools, processes, procedures and governance, that work together to manage the information throughout its lifecycle, including maintenance, validation and archival or disposal.

The methodology also involves the application of management techniques to collect information, communicate it within and outside the organisation, and process it to enable managers to make quicker better decisions.

The Information Management Framework is the vehicle for addressing Information Quality Issues and establishing the associated information governance structures, principles and processes.

1.3        Objectives

The Information Quality Framework document will provide the subcomponent of the Information Management Framework. It will describe the quality principals used to support the overall quality Framework.

2                 Information Quality Principles

The Information Quality Principles are derived from and support the Information Management Principles. They define the specific information quality premises that serve as the foundation for the courses of actions for information / data quality within . 

The six (6) Information Quality Principles are:

2.1.1    IQ Principle 1: Fact-based decision making

Both strategic and operational decisions are based on facts that can be sourced back to data / information that is held by .

2.1.2    IQ Principle 2: Integrated data with consistent definitions

One of ’s major assets is information. Each Division or unit is part of the whole and can leverage enterprise information assets in an integrated and synergistic way (that is, the whole is greater than the sum of parts).

2.1.3    IQ Principle 3: Appropriate retention of detailed data

Information is retained whenever physically possible within the constraints of government legislation, corporate ethics and privacy commitments.

2.1.4    IQ Principle 4: Quality of data will be measured

Decision makers not only need access to information, but more importantly they also need to understand the timing, reconciliation, completeness and accuracy of that data.

2.1.5    IQ Principle 5: Appropriate enterprise access

Every member of staff is trusted to handle information appropriately and sensitively. The default position is that a staff member can access information unless there is a specific commercial, legal or ethical reason as to why not.

2.1.6    IQ Principle 6: Every data item has one person or role as ultimate custodian

Every item of data requires unique and ultimate custodianship by a single role and person to ensure that issues or conflicts always have an ultimate point of escalation.