This process explains how Data Engineering (DE) and Analytics Reporting (A) work together to turn a business need into a trusted, production-ready report.
It’s designed for non-technical managers: no jargon, just what happens, who’s responsible, and what the outcomes are.
Phase 0: Definition – Ground Zero
Purpose
Lay the foundation before vision-shaping begins. Ensure clarity on scope, ownership, and ways of working.
Steps
- Context: Define the business area, system(s), or process the report relates to.
- Scope: Agree what is in/out of scope at the very start (e.g. “customer invoicing only, not supplier payments”).
- Objectives: Clarify the high-level goals (e.g. improve visibility, reduce manual effort, support decision-making).
- Stakeholders: Identify the manager, reporting lead, data team contact, and any other roles involved.
- Governance & Ownership: Establish who owns the data, the process, and the final reporting product.
- Ways of Working: Set expectations for communication, documentation, and sign-off (e.g. Teams channel, cadence of check-ins).
- Constraints: Note any known blockers or boundaries (e.g. regulatory requirements, licensing, data privacy).
Responsibilities
- Manager: Define scope and business objectives.
- Reporting Lead: Capture initial expectations of reporting needs.
- Data Team: Advise on feasibility and ensure alignment with data governance.
Outcome
- A shared starting brief (one-page or equivalent).
- Agreement on who is involved, what’s in/out, and why this matters.
- Confidence that all parties are aligned before moving to “Dream” mode in Phase 1.
Phase 1: Dream – Shaping the Vision
Purpose
Capture what the manager wants to see, without technical detail.
Steps
- Who
- Who is likely to use this report?
- Which roles or teams will benefit?
- Where
- Show us what you have today (screenshots, exports, existing reports).
- Highlight pain points or gaps.
- Why
- What happens in your day that prompts you to look at this report?
- What decisions or actions will it support?
- What
- What information do you expect the report to provide?
- Are there specific metrics, fields, or breakdowns that matter most?
- How
- Show us what you want to see in the future.
- Describe the KPIs, charts, or storylines (e.g. “I want to track order cancellations by region over time”).
Responsibilities
- Manager & Reporting:
- Share context, examples, and business priorities.
- Explain the “why” behind the need, not just the output.
- Data Team:
- Listen actively and ask clarifying questions.
- Translate needs into plain English requirements before any technical design.
Outcome
- A clear, agreed statement of “what good looks like” in reporting.
- A shared understanding of the underlying business questions the report must answer.
- Confidence that both business and data teams are aligned before any build begins.
Phase 2: Discover – Understanding the Source
Purpose
Establish what data exists and how we can reach it.
Steps
- Interaction: Define how the system shares data (API, file export, database).
- Ownership: Identify a technical/system lead in their team.
- Mapping: Compare “what you want” with “what the system holds”.
- Map requested KPIs to available system data.
- Check whether supporting data already exists in the warehouse.
Responsibilities
- Manager: Nominate a contact who knows the system.
- Technical Lead: Help the Data Team understand field names/exports.
- Data Team: Lead discovery of data sources, Document feasibility and flag gaps.
- Reporting: Support and validate mapping.
Outcome
- A basic source-to-requirement map.
- Agreement on what is possible versus what may not exist.
Phase 3: Develop – Building the Foundations
Purpose
Capture the minimum data needed for a DataMart and Reporting.
Steps
- Data Team Essentials:
- Country / Company
- Object or Entity ID (project, employee, customer, etc.)
- Item or Activity sequence
- Principal/Lead/Owner/Manager (preferably with email)
- Customer/Client/Employee (preferably with email)
- Principal date (for events/activities)
- Categories or slicers (e.g. type, status, region)
- Reporting Essentials:
- Confirm whether requirements in Phase 1 are fully visible in the system.
- Note where additional warehouse data could enrich the report.
- Collaborate on 3 types of unique identifier:
- Source identifier (system origin)
- Business identifier (user-facing)
- Warehouse identifier (links across marts)
- Flag “wish list” items that don’t exist.
- Prioritise using MoSCoW (Must, Should, Could, Won’t).
Responsibilities
- Data Team & Reporting: Jointly define essential data and identifiers.
- Data Team: Build structured Attribute Lineage, requirements notes; confirm gaps.
- Manager: Validate priorities and clarify which data really matters.
Outcome
- Structured requirement list and documented lineage.
- Early decisions about feasibility and scope.
Phase 4: Deliver – Making it Tangible
Purpose
Prove that the data works and reflects the business story.
Steps
- Data Team
- Build a wireframe or prototype report (may look “rough”).
- Validate: does this reflect the KPIs and visuals requested?
- Identify whether metrics appear correct or highlight where further discovery is needed.
- Reporting
- Build a first sketch of the report.
- Validate calculations and measures.
- Loop back if discrepancies are found.
Responsibilities
- Reporting: Lead sketch & validation.
- Data Team: Support with data adjustments.
Outcome
- A testable “first look” report.
- Clear next steps for adjustments.
Phase 5: Document – Finalising Outputs
Purpose
Finalise the report and ensure repeatability.
Steps
- Reporting:
- Finalise proposal for production report.
- Write down the clear business definitions for each KPI or measure (e.g. what counts as “active customers”).
- Capture refinements as Phase 2 of the reporting cycle.
- Keep a record of any assumptions or exclusions agreed during development.
- Share with manager and technical lead for testing.
- Create a simple reference (data dictionary / metric guide) that others can follow.
- Finalise proposal for production report.
- Data Team:
- Document the DataMart build.
- Capture the data sources, data types, and how they link together.
- Record lineage and dependencies.
- Ensure the process is repeatable.
- Document the DataMart build.
Responsibilities
- Reporting: Define production report.
- Data Team: Document and make repeatable.
What we need you (the customer) to do
- Confirm that the written definitions reflect your understanding.
- Help resolve any grey areas (“does this include cancelled orders or not?”).
- Approve the final list of metrics and attributes as the official version.
Wider dependencies
- Agreement from any other teams who will also use these metrics (to ensure one version of the truth).
- A central place to store this documentation (e.g. a shared site or catalogue) so it is easy to find later.
Outcome
A repeatable, reliable data model and metric set that can be reused for future reports or extended without starting from scratch.
Phase 6: Deploy – Go Live & Support
Purpose
Release to production with trust and security.
Steps
- Reporting: QA, apply security, publish report.
- Manager: Confirm usability.
- Data Team: Ensure DataViews are in production and refresh correctly.
Responsibilities
- Reporting: Lead deployment.
- Data Team: Support stable production DataViews.
Outcome
Trusted, live reporting solution.
Phase 7: Review & Evolve (Optional)
Purpose
Keep the report relevant as needs change.
Steps
- Gather feedback from users.
- Check metrics still align with business needs.
- Feed new requests back into Phase 2 (Discover).
Responsibilities
- Reporting: Lead review.
- Data Team: Support updates if needed.
Outcome
Reporting evolves with the business.
👉 Suggestion: You could add a summary table at the top for quick scanning:
| Phase | Purpose | Lead | Outcome |
|---|---|---|---|
| Define | Define scope, objectives, priorities | Process Owner | Shared Engagement and Context |
| Dream | Capture vision | Manager & Reporting + Data Team | Shared “what good looks like” |
| Discover | Understand data source | Data Team | Feasibility map |
| Develop | Define essentials | Data Team & Reporting | Structured requirements |
| Deliver | Build prototype | Reporting + Data Team | Working sketch |
| Document | Finalise & document | Reporting + Data Team | Signed-off report design & documentation |
| Deploy | Go live | Reporting | Trusted, secure report |
| Review | Keep relevant | Reporting | Continuous improvement |
Roles & Responsibilities
Process Owner / Manager
Non-Technical Lead who owns the business process the report supports. Defines objectives, scope, and priorities. Provides context, validates whether outputs answer the right business questions, and approves the final result.
Technical Lead
Technical Lead who understands the source system(s). Advises how data can be accessed and what fields mean. Provides exports, field definitions, and helps bridge between business needs and technical feasibility.
Data Engineer
Builds and maintains the data pipelines and DataMart structures. Ensures data quality, lineage, and repeatability. Implements identifiers, manages integrations, and supports stability in production.
Reporting Lead
Designs and develops the report itself. Translates business requirements into visuals, measures, and KPIs. Validates outputs with the business, applies security, and ensures usability and clarity of the final reporting product.
RACI Grid for Reporting Lifecycle
| Phase | Process Owner / Manager | Technical Lead | Data Engineer | Reporting Lead |
|---|---|---|---|---|
| 0. Definition – Ground Zero | A/R: Define scope, objectives, priorities | C: Advise on constraints/feasibility | C: Highlight data availability/risks | C: Advise on reporting expectations |
| 1. Dream – Shaping the Vision | A/R: Share vision, pain points, desired outcomes | C: Clarify system limits | C: Listen, note dependencies | R: Capture requirements in plain English |
| 2. Discover – Understanding the Source | C: Nominate system contact | A/R: Explain fields, exports, access | R: Map data to requirements, flag gaps | C: Validate mapping against reporting needs |
| 3. Develop – Building the Foundations | A: Validate priorities | C: Confirm field meanings | A/R: Build identifiers, lineage, structure | R: Note enrichments, validate essential data |
| 4. Deliver – Making it Tangible | A: Validate whether prototype answers the right questions | C: Support with system detail if needed | R: Build prototype DataMart / adjust data | A/R: Build report wireframe, lead validation |
| 5. Document – Finalising Outputs | A/R: Approve KPI definitions, confirm grey areas | C: Validate technical assumptions | R: Document DataMart build & lineage | A/R: Document business definitions, finalise report |
| 6. Deploy – Go Live & Support | A: Confirm usability in production | C: Ensure system security compliance | R: Support stable production DataViews | A/R: Lead QA, apply security, publish |
| 7. Review & Evolve | A/R: Provide feedback, confirm ongoing relevance | C: Confirm any system changes | R: Support updates to DataMart if needed | A/R: Lead review, gather feedback, refresh reporting |
A (Accountable) – Owns the decision and outcome.
C (Consulted) – Provides input.
I (Informed) – Kept in the loop.
Task Lists
Phase 0: Definition – Ground Zero
Task List
- Confirm business area / process in scope
- Identify project manager / reporting lead
- Identify data team lead / technical contact
- Capture high-level objectives (why this matters)
- Agree what’s in scope and what’s explicitly out of scope
- Capture known constraints (compliance, cost, timeline, tools)
- Agree communication channel and frequency (Teams, email, meetings)
- Draft and sign off “Ground Zero Brief”
Phase 1: Dream – Shaping the Vision
Task List
- Identify target audience / users of report
- Gather current reports, exports, screenshots
- Capture pain points / gaps in current state
- Capture triggers (what prompts looking at report)
- Capture intended actions/decisions supported
- Gather list of desired information, fields, or metrics
- Capture future vision: KPIs, charts, storyline examples
- Agree initial statement of “what good looks like”
Phase 2: Discover – Understanding the Source
Task List
- Confirm system(s) holding relevant data
- Identify technical/system owner
- Identify method of access (API, file export, DB connection)
- Map desired KPIs to available data fields
- Check if supporting data exists in warehouse already
- Flag gaps or missing elements
- Draft source-to-requirement map
- Review feasibility with manager & reporting team
Phase 3: Develop – Building the Foundations
Task List
- Define essential entities (Country/Company, IDs, sequences)
- Define ownership (manager, lead, customer/employee identifiers)
- Confirm principal dates & slicers/categories needed
- Identify 3 identifiers (Source, Business, Warehouse)
- Flag wish-list items and non-existent data
- Prioritise items using MoSCoW
- Draft attribute lineage for requirements
- Validate with manager what data really matters
Phase 4: Deliver – Making it Tangible
Task List
- Build prototype DataMart/DataView
- Build wireframe/prototype report (rough is fine)
- Validate visuals: do they match Phase 1 expectations?
- Validate metrics: do they calculate correctly?
- Capture discrepancies or missing data
- Iterate with reporting team
- Agree “first look” output
Phase 5: Document – Finalising Outputs
Task List
- Finalise business definitions for KPIs/metrics
- Document exclusions/assumptions
- Confirm definitions with manager & technical lead
- Create reference guide (dictionary / metric guide)
- Document DataMart build (sources, types, lineage)
- Ensure process repeatability
- Store documentation in central location
- Gain approval of final metric list
Phase 6: Deploy – Go Live & Support
Task List
- QA final report
- Apply security & access controls
- Publish report in production environment
- Ensure DataViews refresh correctly
- Manager validates usability in production
- Agree ongoing support model
- Close development phase
Phase 7: Review & Evolve
Task List
- Gather feedback from users
- Review whether KPIs still answer business questions
- Capture new requests
- Feed new items back into Phase 2 (Discover)
- Agree timeline for regular review (quarterly, annually, etc.)