Wednesday, 10 March 2010

Data Quality Principles within the PMO

According to Wikipedia, the Project Management Office (PMO) is:

"the department or group that defines and maintains the standards of process, generally related to project management, within the organization. The PMO strives to standardize and introduce economies of repetition in the execution of projects. The PMO is the source of documentation, guidance and metrics on the practice of project management and execution."

It then goes on to state that:

"A good PMO will base project management principles on accepted, industry standard methodologies such as PMBOK or PRINCE2. Increasingly influential industry certification programs such as ISO9000 and the Malcolm Baldrige National Quality Award (MBNQA) as well as government regulatory requirements such as Sarbanes-Oxley have propelled organizations to standardize processes. Organizations around the globe are defining, borrowing and collecting best practices in process and project management and are increasingly assigning the PMO to exert overall influence and evolution of thought to continual organizational improvement."

With this in mind it would seem sensible to suggest that a number of Data Quality Principles should be documented, and executed within the PMO space.

However, within some organisations, I have witnessed the PMO disregard fundamental Data Quality principles, that, if applied at the start of a project would have saved time and money spent on 'scrap & rework' or downstream effort to implement these principles once a project has gone live.

I'm a DQ Professional - What can I do?

You can define principles of data quality and position yourself as a trusted advisor to the PMO, consulting within each new project that either consumes, or produces, data/information. Your role will become more about prevention, improving confidence in data and ensuring that the correct governance is in place for each new project.

It sounds time consuming

But it doesn't have to be. By defining a number of principles that must be met to ensure a project can successfully be signed off, we can create guidelines that if followed can aid project success. Data quality is all too often an after thought, or a one-off profiling exercise that will, time-permitting, be undertaken during the early stages of a project. We need to change this mindset, and embed a culture of data assurance & governance within each new project.

With this in mind, here are some principles to consider:

Principle #1 - Data Quality Assurance

Any project utilising data should ensure that it's source data has been profiled and analysed, with any potential data quality issues identified. Actions to resolve issues should be documented, alongside any perceived risks with the current/future state of data.

Principle #2 - Data Lineage

Documenting data lineage will increase user confidence in data, and aid with the satisfaction of regulatory compliance. The items that should be documented within our Data Lineage exercise include:

Business Rules
Data Transfer Methods
Aggregation Rules
Load Schedules

Principle #3 - Data Dictionary

Both technical, and business metadata should be captured within the project scope. This again will increase confidence, and knowledge of data, data structures and information produced within the project.

Principle #4 - Reference Data Management

Any reference data utilised within a project should be identified and centrally managed. The process for maintaining reference data should be documented, and if necessary, should be associated with 'data stewards' responsible for it's maintenance.

Principle #5 - Data Classification

Data Classification was something I touched on previously as a method to ensure that reports were efficiently stored. It is also a critical exercise to undertake in terms of Security & Access Control. Any reporting outputs that will be created within a project should be classified accordingly.

Principle #6 - DQ Team Engagement

To ensure adherence and satisfaction, the Data Quality team should be involved in the project sign-off process. Only when data quality/governance concerns have been satisfied should the project be signed off.

In Summary

In many organisations projects are often silo'd in approach, with the scope of data quality/governance effort applied to each new project varying significantly, depending upon user requirements, time, and other factors. By involving the Data Quality team within each project we can start to build standards, add value and increase data confidence in new project implementation. While at the same time increasing business awareness of our function, confidence in our service and centralisation of our improvement efforts.


Phil Simon said...


Great post. I'm 100% in agreement with you but have never seen even half of these followed on any one project.

Perhaps that's why my first book is called "Why New Systems Fail."



Phil Wright said...

I know. I'm adamant that if more DQ teams aligned themselves with the PMO in this way we'd see less failure in data driven projects.

Post a Comment