Learning Objectives
By the end of this lesson you will be able to:
- Describe the purpose of a DQR dashboard and its intended audiences
- Identify the key metrics a DQR dashboard should display
- Explain how dashboard design supports both DQR Board operations and programme reporting
Why a Dashboard?
As the DQR list grows - and on a large project it will grow to hundreds of items across multiple KBDAs and LDS - ad hoc reporting becomes unmanageable. The DQR Board needs to see what needs attention now. Programme management needs to see overall migration readiness. Data Owners need to see the status of their data area.
A well-designed DQR dashboard serves all three audiences from a single data source.
Dashboard Audiences
DQR Board (operational) Needs to see:
- Which items are red/amber and need discussion at this meeting
- Priority 1 items that are at risk of missing migration deadlines
- Items with upcoming sub-task due dates
- New items raised since the last meeting
Programme Management (strategic) The strategic view is of migration readiness, not readiness as a whole. It needs to show:
- Trend data: is the list growing, stable, or shrinking?
- Outstanding Priority 1 items that could delay go-live
- High-level status of each LDS
Data Owners (business) Needs to see:
- Status of DQR items for their data area
- What is being asked of their BDEs
- Progress since the last review
Key Metrics to Display
| Metric | Description |
|---|---|
| Total open DQR | Count of all open items, by priority |
| Red/Amber/Green by priority | Traffic-light view of progress |
| % records migration-ready | By KBDA and overall |
| DQR completion dates vs. migration run dates | Gap analysis to identify timing risks |
| DQR outcome distribution | Fix in Source, Fix in Flight, Fix in Target, Fallout in Flight, Don’t Fix |
| Late-running items | Items past due date |
| DQR by LDS | Distribution of issues across the landscape |
| Newly raised vs. closed (trend) | Is the backlog growing or shrinking? |
Design Principles
Keep it simple. A dashboard that requires a five-minute explanation is not doing its job. The DQR Board should be able to look at the dashboard and immediately identify what needs discussion.
Use traffic lights consistently. Green = on track, Amber = at risk, Red = blocked or late. Apply the same criteria across all DQR items so that comparisons are meaningful.
Separate views by audience. The DQR Board needs operational detail; programme management needs a summary. A single dashboard with tabs or views for each audience is better than multiple disconnected reports.
Connect to migration run dates. A DQR item that is amber six weeks before a migration run is a different risk than one that is amber six hours before. The dashboard should make this timing relationship explicit. Note that an amber DQR can be a candidate for Fallout in Flight or Don’t Migrate. The dashboard should focus on top-priority DQR items, not attempt to show every item at every level of detail.
Technology Considerations
The DQR repository can be as simple as a shared spreadsheet or as sophisticated as an integrated issue management system. The dashboard should be built on top of whichever repository is used.
For most projects, a well-structured spreadsheet with summary pivot tables and conditional formatting for traffic lights is sufficient. Purpose-built data quality tools are available but introduce implementation overhead that may not be justified on smaller projects.
What matters is not the technology but the disciplines:
- All DQR items in one place
- Version control on the repository
- Regular updating before each DQR Board meeting
- Consistent metric definitions
Key Takeaways
- A DQR dashboard serves three audiences: DQR Board (operational), Programme Management (strategic), Data Owners (business)
- Key metrics: open DQR by priority, traffic-light status, % records migration-ready, timing gap to migration run dates
- Design principles: simple, consistent traffic lights, audience-specific views, connected to migration dates
- Technology is secondary to process discipline - a well-run spreadsheet beats a sophisticated tool that nobody updates
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 05 - Introducing DQR