Connecting the work to the boardroom

• Tell me about the business outcome you need this platform to deliver in the next 12 months.
• How will your executive team quantify success for that outcome, in metrics or dollars? Options: Change in reported revenue variance, Reduction in reconciliation time, Faster close cycle, Cost savings in reporting operations, Other
• Which existing reports or KPIs cause the most executive debate today? Options: Monthly revenue summary, Customer lifetime value, Sales funnel conversion, Inventory valuation, Other
• Estimate how frequently conflicting numbers appear across departments in a typical quarter. Options: Multiple times per month, Once per month, A few times per quarter, Rarely
• Who are the primary downstream consumers of those reports, and what decisions do they make from them?
• If this program succeeds, what is the single operational change executives will expect to see within six months?
• State the person or role that has final authority to approve budget for full implementation if the pilot proves outcomes.

Mapping where your truth lives today

• If a key dashboard refreshed tomorrow and showed the wrong revenue number, which systems would you investigate first and why?
• List the primary source systems, scheduled extracts, and manual files that currently feed reporting.
• For each source, who controls access and who is the data steward responsible for quality?
• Which sources are delivered by scheduled APIs versus manual exports or spreadsheets? Options: Scheduled API or connector, Regular automated extract, Ad hoc manual extract, Spreadsheet shared by email, Third-party batch file
• How frequently are source extracts refreshed, and which ones are known to run late or fail? Options: Near real time, Hourly, Daily, Weekly, Ad hoc/manual
• Do any sources require legal or vendor approvals before a third party can connect to them? Options: Yes, vendor contract required, Yes, internal legal approval needed, No approvals required, Unknown
• Confirm whether you would pause the pilot or accept a reduced scope if a critical source cannot be accessed within four weeks. Options: Pause until access is granted, Proceed with reduced scope, Decide case by case, Not applicable

Where trust breaks down in your reports

• What single data error last quarter triggered a corrective action or a board-level question?
• Describe how often pipeline failures go unnoticed until an executive dashboard shows incorrect data. Options: Almost always, Often, Sometimes, Rarely, Never
• Name the monitoring or alerting that currently detects stale or incomplete data, and who receives those alerts.
• Quantify the business impact when dashboards are stale, in hours of delayed decisions or estimated revenue at risk per quarter.
• Would your executive team halt or scale back the project if these trust issues remain unaddressed? Options: Yes, likely pause, Yes, scale back scope, No, proceed with caution, Unsure

Who needs to be in the room to make changes stick

• Who would need to approve schema changes, source access, or production alerts for the pilot to move forward?
• List the roles that must be available during the pilot, such as data steward, platform engineer, BI lead, or legal reviewer. Options: Data steward, Platform engineer, BI lead, Product owner, Legal/compliance, Other
• Name any stakeholders who have veto power over scope or go-live decisions.
• Estimate the number of full time equivalents your team can dedicate to the pilot, and note any planned hires in the next quarter.
• Will you pause or proceed with a limited-scope pilot if stewardship roles are not assigned within six weeks? Options: Pause until roles assigned, Proceed with limited scope, Proceed but escalate risks, Unsure

The other paths you're considering

• What measurable condition would have to be true for you to keep your current setup instead of changing it?
• Tell me which internal teams or initiatives have proposed a DIY build or owning the platform in-house.
• Select the alternative approaches you are actively evaluating. Options: Extend current extracts and reports, Internal build by engineering, Purchase packaged analytics solution, Engage a different external partner, Hybrid approach
• Describe the proofs or data points that would convince you the current approach is sufficient.
• Identify any blockers that would prevent you from signing a full engagement within two weeks even after a successful pilot.

Hard prerequisites that make or break timelines

• Identify a connector or API that, if unavailable, would force you to delay the pilot, and name its owner.
• Do you currently have an environment we can use for a pilot within four weeks, such as a dev or sandbox cloud account? Options: Yes, ready now, Yes, needs minor setup (1-2 weeks), No, requires provisioning (2-6 weeks), No, not available
• Provide the number of engineers or data analysts with hands-on experience in cloud data platforms and pipeline maintenance.
• For regulated data, what compliance approvals or legal reviews are required before data can be copied to a cloud environment? Options: Data protection review, Vendor security review, Regulatory authority approval, No special approvals, Unknown
• Are there contractual or procurement gates that will block vendor work until a committee meets, and when is that committee next scheduled? Options: Yes, scheduled this month, Yes, scheduled next quarter, No procurement gate, Unknown

Concrete success signals that will close the loop

• Would you consider a phased rollout if the pilot fails to improve report agreement or freshness? Options: Yes, phased rollout, No, would stop work, Depends on fixes, Unsure
• Select the primary acceptance metrics for the pilot. Options: Report reconciliation variance, Data freshness and latency, Incident time to detect, Number of failing pipelines, End user adoption rate
• Specify target thresholds for each selected metric, for example reduce reconciliation variance to under 2 percent or data latency under 15 minutes.
• Provide the individuals or roles who will sign pilot acceptance and summarize the criteria each requires.
• State the latest date your team could commit to start transition work after the pilot meets acceptance.

Small wins that accelerate confidence

• Pinpoint one immediate technical or business win in the first 30 days that would convince leadership to continue funding the project.
• Prioritize the datasets or domains for the pilot, choosing up to three. Options: Finance transactions, Sales CRM extracts, Customer master, Product usage logs, Inventory and supply data, Other
• Indicate the roles that must be available for weekly check-ins and rapid approvals during the pilot. Options: Executive sponsor, Data steward, Platform engineer, BI lead, Legal/compliance
• Outline the top three logistical barriers to starting within two weeks.
• Are budget windows or procurement cycles constraining when you can start? Options: Yes, immediate window missed, Yes, next window in 1-2 months, No, flexible budget, Unsure
• Confirm whether your team can commit to a pilot start date within a 7 day sprint if the first technical blockers are cleared. Options: Yes, No, Need to confirm stakeholders, Only with conditional approvals

• Pilot Use Case Definition
• Pilot Acceptance Criteria and Data Quality SLAs
• Roles, Responsibilities, and Decision Rights (RACI) for Pilot
• Pilot Timeline, Milestones, and Resource Plan
• Pilot Readiness Review and Go/No-Go Decision

• Publish the pilot timeline with milestones, task dependencies, and estimated dates.
• Document required access permissions and provisioning tasks for each role listed in the RACI.
• Create a draft training and handoff checklist for operational readiness.
• List milestone deliverables and acceptance gates
• An agreed pilot timeline with milestones, dependencies, and estimated dates is produced.
• A resource plan that lists required roles and approximate effort windows is documented.
• Each milestone has an acceptance checklist and handoff definition.
• Confirm strategic outcome and success signals
• Confirm and document environment reservation windows and any required maintenance blackout dates.
• Prepare a staffing confirmation request listing the roles and tentative effort windows for stakeholder sign-off.
• Present the consolidated pilot package
• A formal go or no-go decision for pilot start is recorded with rationale.
• If go, a short list of immediate next actions and start date is agreed; if no-go, a remediation plan with owners and due dates is produced.
• All attendees acknowledge the known risks and the mitigation steps that will be tracked during the pilot.
• Publish the go/no-go decision and attach the final pilot package to the project workspace.
• Create and distribute the pre-start remedial tasks list with due dates for any items that must be completed before the pilot can begin.
• Schedule the pilot kick-off meeting and reserve required environment and review windows.
• A one-page pilot use case specification is finalized and accepted by attendees.
• Scope boundaries are clearly documented with explicit in-scope and out-of-scope items.
• A pilot owner is identified to serve as the primary decision contact for the pilot.
• Publish the finalized one-page pilot specification to the shared workspace.
• Compile and share the initial list of source systems and access requirements required for the pilot.
• Schedule the acceptance criteria working session with the pilot owner and technical leads.
• Recap pilot spec and desired success signals
• A signed acceptance criteria list exists with metric definitions, thresholds, and measurement queries or methods.
• A documented set of data quality rules and SLA thresholds that will gate pilot acceptance.
• Monitoring and rollback conditions are documented and understood by stakeholders.
• Publish the acceptance criteria document including measurement queries and the data quality rules list.
• Provide example datasets or query results to validate each acceptance metric before pilot execution.
• List required monitoring and alerting integrations and the required access to configure them.
• Review pilot activities to be performed
• A completed RACI matrix listing role titles for each pilot activity is agreed and recorded.
• An explicit escalation and decision rights document is produced and accepted.
• A list of required onboarding and training items for post-pilot handoff is captured.
• Publish the RACI matrix and escalation path to the shared workspace.
• Select and describe the pilot use case
• Sequence tasks, identify dependencies, and estimate durations
• Run the readiness checklist against acceptance gates
• Map roles to activities to produce a RACI matrix
• Define measurable acceptance criteria
• Specify data quality rules and SLA thresholds
• Confirm escalation path and final decision authority
• Review open risks, blockers, and mitigation plans
• Define scope in and scope out for the pilot
• Validate resource availability and constraints
• Map primary data sources and known constraints
• Agree on milestone acceptance criteria and handoff points
• Decision and required pre-start actions
• Agree monitoring, alerting, and rollback conditions
• Identify onboarding, handoff, and training requirements
• Document pilot spec and confirm pilot owner

• Solution Experience Session

• Confirm the current state and its cost
• You confirm the restated current state and agree on the cost statement for your organization.
• Provide a one-page architecture runbook for the prioritized use case before pilot kickoff.
• You confirm that the demonstrated end-to-end flow and monitoring prevent the manual reconciliation and risk described in Discovery.
• End-to-end flow for the prioritized use case
• Provide a representative sample extract and a scoped list of source access needed for the pilot.
• Show monitoring, alerts, and remediation paths
• You agree on the remaining evidence required before a decision, including pilot acceptance criteria and timeline.
• Finalize pilot acceptance criteria and timeline within five business days after this session.
• Adoption and handoff plan with roles and timeline
• Validate the future state

• Solution Experience Session
• Solution Experience Deck
• Solution Brief

• meeting
• slides
• document

• Build ingestion and transform pipelines for CRM domain
• Implement change-data-capture (CDC) pipelines for transactional sources
• Develop canonical enterprise data model with silver/gold layers
• Create dimensional data marts for finance and revenue reporting
• Implement ELT orchestration, scheduling, and retry logic
• Deploy automated data quality checks and remediation workflows
• Set up pipeline monitoring, alerting, and SLA incident routing
• Migrate historical records and backfill into the new platform
• Implement metadata catalog and end-to-end data lineage capture
• Configure role-based access controls and row-level security
• Optimize compute and storage for query performance and cost
• Provision BI semantic layer and deliver executive dashboards
• Deliver operations runbooks and train internal data engineering team

Build ingestion and transform pipelines for CRM domain

• Which CRM objects need ingestion for the pilot (contacts, accounts, opportunities, activities, custom objects)? Options: Contacts, Accounts, Opportunities, Activities, Custom objects
• How many daily change rows for contact and account tables should the pipelines be sized for? Options: Less than 1,000, 1,000-10,000, 10,000-100,000, More than 100,000
• Do you require a source-to-target field mapping document for the contact object before development? Options: Yes, No
• Specify required data quality thresholds for CRM contact records (for example email completeness >= 95%, duplicate rate < 1%) Options: Email completeness >= 95%, Duplicate rate < 1%, Custom threshold
• Who will own schema approval and sign off on transformed CRM tables?
• Are there regulatory or PII masking requirements on CRM fields (national ID, birthdate, payment info)? Options: Yes, No

Implement change-data-capture (CDC) pipelines for transactional sources

• List the transactional sources to enable CDC for the pilot (order system, payment gateway, billing ledger)? Options: Order system, Payment gateway, Billing ledger, Other transactional source
• What end-to-end latency from source commit to platform landing do you require for CDC events? Options: Near real-time (<= 1 minute), Within 5 minutes, Within 15 minutes, Daily batch
• Do the sources provide native CDC streams (database change log, message queue) or will we use timestamp-based snapshots? Options: Native CDC stream, Timestamp-based snapshots, Other
• How many tables per source should CDC cover in the pilot? Options: 1-5, 6-20, More than 20
• What defines successful CDC delivery for a transactional table (allowed change loss, offset lag threshold, or reconciliation evidence)? Options: Zero row loss expected, Offset lag < 2 minutes, Reconciliation report within 0.01% variance, Custom
• Who is the contact responsible for resolving CDC connector failures during the pilot?

Develop canonical enterprise data model with silver/gold layers

• Identify the enterprise entities required in the canonical model for the pilot (customer, product, ledger, sales order)? Options: Customer, Product, Ledger, Sales order, Other
• What naming convention and partitioning standard should be applied to silver and gold tables?
• Do you require surrogate keys and slowly changing dimension type 2 support for customer and product entities? Options: Yes, No
• Specify reconciliation acceptance for gold-layer aggregates to source ledgers (for example totals match within 0.1%) Options: Totals match within 0.1%, Totals match within 1%, Custom threshold
• Who will review and approve the canonical model design and field-level definitions?
• Are cross-domain joins required in the gold layer (for example linking finance ledger to CRM customer)? Options: Yes, No

Create dimensional data marts for finance and revenue reporting

• List the revenue reporting use cases the finance mart must support in the pilot (monthly revenue by product, ARR, churn cohorts)? Options: Monthly revenue by product, Annual recurring revenue (ARR), Churn cohorts, Custom use case
• How many source systems will feed the finance marts (ERP, billing, payments)? Options: 1, 2, 3+
• Do you require fiscal calendar alignment and SCD support in the finance star schema? Options: Yes, No
• Provide the authoritative KPI definitions to include in the mart (net revenue, gross margin, recognized revenue)?
• Who will sign off on revenue reconciliations between the mart and the general ledger?
• Is migration of prior fiscal year data into the mart required for comparatives? Options: Yes, No

Implement ELT orchestration, scheduling, and retry logic

• Which orchestration approach should be used for the pilot (your existing scheduler, cloud-native orchestration, orchestration-as-code)? Options: Existing scheduler, Cloud-native orchestration, Orchestration-as-code (DAGs), Other
• What retry policy and backoff strategy should apply to failed ELT jobs? Options: 3 retries, linear backoff, 5 retries, exponential backoff, No retries, manual intervention
• Do you require business-hour aware scheduling and SLA windows for finance pipelines? Options: Yes, No
• Who will own orchestration runbooks and escalation steps for missed schedules?
• Specify monitoring thresholds that should mark an orchestration run as failed (for example duration > 1 hour, task error rate > 5%) Options: Duration > 1 hour, Duration > 4 hours, Error rate > 5%, Custom
• Is support for ad-hoc backfills and DAG replays required for the pilot? Options: Yes, No

Deploy automated data quality checks and remediation workflows

• Which data quality checks must run for CRM and finance (null rate, uniqueness, referential integrity, value ranges)? Options: Null rate, Uniqueness, Referential integrity, Value range checks, Other
• What thresholds should trigger automated remediation versus human review for a failed check? Options: Auto-remediate if failure < 0.5% of rows, Human review if failure > 1% of rows, Custom threshold
• Do you want automated remediation actions (re-run extraction, apply defaults, create ticket) for specific failures? Options: Yes, No
• Who will approve quality change requests and remediation playbooks?
• How should remediation events be recorded for audit (ticket ID, remediation log, both)? Options: Ticket ID, Remediation log, Both, Other
• Is integration with your incident management system required for data quality escalations? Options: Yes, No

Set up pipeline monitoring, alerting, and SLA incident routing

• Identify the channels that should receive pipeline alerts (email, Slack channel, paging, incident management)? Options: Email, Slack channel, Paging, Incident management system
• What SLA for data freshness should trigger incident routing (for example daily delivery by 06:00 UTC)? Options: Daily delivery by 06:00 UTC, Within 1 hour of business window, Custom SLA
• Do you require multi-tier alert severity with different recipient lists? Options: Yes, No
• Who acts as incident commander for SLA breaches during business hours and after hours?
• List the monitoring metrics to surface on the dashboard (latency, success rate, row counts, schema drift)? Options: Latency, Success rate, Row counts, Schema drift, Other
• Are synthetic canary runs required to validate pipelines before production windows? Options: Yes, No

Migrate historical records and backfill into the new platform

• How many years of historical data must be migrated per domain (CRM contacts, orders, invoices)? Options: None, 1 year, 3 years, All available history
• What completeness threshold defines a successful backfill (for example 99.5% of source rows reconciled)? Options: 99.5% reconciled, 99% reconciled, Custom threshold
• Should historical records be transformed to canonical keys or preserved as raw snapshots? Options: Transform to canonical keys, Keep raw snapshots, Hybrid approach
• Who will provide access to legacy database exports and schedule large extracts for migration?
• Are there extraction blackout windows or performance constraints on the source systems? Options: Yes, No
• Should incremental backfill be staged and validated before final cutover? Options: Yes, No

Implement metadata catalog and end-to-end data lineage capture

• Which metadata attributes must be captured (schema, column descriptions, owners, sensitivity tags)? Options: Schema, Column descriptions, Owners, Sensitivity tags, Other
• Do you require automated lineage capture from source tables through ETL to dashboards? Options: Yes, No
• What classification taxonomy should be used for data sensitivity (PII, PCI, PHI, public)? Options: PII, PCI, PHI, Public, Custom
• Who will be nominated as data stewards to appear in the metadata catalog?
• Is mapping between BI dashboard fields and underlying gold-layer tables required for traceable lineage? Options: Yes, No
• Which retention period should be applied to metadata change history (1 year, 3 years, 7 years)? Options: 1 year, 3 years, 7 years, Custom

Configure role-based access controls and row-level security

• Which user groups need access to which domains (analytics, finance, operations, executive)? Options: Analytics, Finance, Operations, Executive
• Do any tables require row-level security based on user attributes such as region or cost center? Options: Yes, No
• What authentication method will integrate with the platform (identity provider single sign-on, local accounts)? Options: Identity provider single sign-on, Local accounts, Other
• Who will approve access requests and conduct periodic access reviews for sensitive datasets?
• Is separation of duties required between transformation engineers and data consumers for production gold assets? Options: Yes, No
• Specify any regulatory time-bound access restrictions for finance datasets (for auditors or read-only windows).

• stakeholders
• gaps
• current_state
• success_criteria
• desired_state
• decision_readiness
• current_state
• decision_readiness
• stakeholders
• desired_state
• success_criteria
• gaps
• current_state
• desired_state
• gaps
• success_criteria
• stakeholders
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Commercial Terms & Order Form
• Acceptance Criteria & Signoff
• Transition & Knowledge Transfer Plan
• Post-Engagement Support Agreement
• Service Level Agreement (SLA) Annex
• Data Processing Addendum (DPA)
• Change Order Agreement
• Termination & Exit Plan

• Go-live health check (weeks 1-4)
• First outcome measurement (weeks 4-10)
• 90-day realization and incumbent decommission check
• Quarterly operational review (ongoing)
• Annual sustain and improvement review

• Publish the prioritized enhancement plan with scope and target quarters for delivery.
• Agree a timebound plan to close remaining high-priority incidents and schedule the ongoing review cadence.
• Produce and circulate an incumbent decommission record listing archive locations, read-only decisions, and any contract or renewal actions taken.
• Publish the 90-day outcomes packet including metric exports, incident timelines, and runbook locations.
• Create a timebound remediation plan for remaining high-priority items with target resolution dates.
• Operational metrics trend review
• Confirm quarterly direction for weekly active users and data freshness SLA compliance relative to Solution Scope targets and identify any corrective priorities.
• Finalize the prioritized enhancement list for the next quarter with delivery windows.
• Ensure governance roles and monitoring coverages are current and operational.
• Re-confirm deployment checklist and owners
• Update the monitoring playbook with any new alert thresholds and documented on-call steps.
• Document any governance role changes and the plan to fill role gaps with timelines.
• Annual outcome summary
• Validate annual performance against Solution Scope targets for manual reporting effort, active usage, and data quality and identify any unresolved systemic issues.
• Agree the top 3 improvement initiatives for the coming year and define measurable success signals for each.
• Set the sustained operating rhythm for quarterly reviews, incident triage, and enhancement delivery.
• Publish the annual outcomes report with recommended top 3 initiatives and associated success signals.
• Create a one-year improvement roadmap with milestones, owners, and measurement criteria.
• Confirm the calendar for quarterly operational reviews and the format of the recurring reporting pack.
• Confirm the deployment items referenced in the Delivery Acceptance Checklist are complete or have documented owners and target dates.
• Identify and prioritize any showstopper incidents and agree remediation targets to restore normal operations.
• Establish the short-term communications plan for user onboarding and incident updates.
• Publish a consolidated incident and remediation tracker with target dates and status updates.
• Provide access verification logs and a checklist of failed/ok connectivity checks for audit.
• Circulate the onboarding progress summary and recommended next steps for end-user training.
• Present first metric results
• Determine whether hours per week spent on manual reporting and weekly active users are trending toward targets recorded in Solution Scope and identify any shortfalls.
• Agree a prioritized corrective action plan with specific target dates to address the highest-impact root causes.
• Establish the evidence pack required for the 90-day realization review.
• Publish annotated metric snapshots and a short analysis of each anomaly identified in the measurement period.
• Create a prioritized remediation list for data quality and onboarding issues with target dates for each item.
• Schedule the 90-day realization review and circulate the evidence pack template to stakeholders.
• Present 90-day outcome metrics
• Confirm that data quality pass rate and mean time to detect pipeline failures meet or are demonstrably improving toward the targets recorded in Solution Scope.
• Verify the legacy system is either fully decommissioned or retained-read-only with archives and contract actions documented, removing the fallback habit risk.
• Deployment and connectivity validation
• Diagnose gaps and root causes
• Review long-running incidents and systemic gaps
• Review incident and enhancement burn-down
• Enhancement and backlog prioritization
• Incumbent system decommission status
• Agree next-year improvement priorities
• Agree corrective actions and owners
• Governance and role review
• Early adoption signals and usage patterns
• Operational handoff and runbook validation
• Blockers and open incidents triage
• Confirm sustained operational cadence
• Confirm timeline to the realization review
• Monitoring and alerting health
• Immediate remediation actions
• Open action item review
• Agree remediation schedule and improvement cadence