Last quarter we audited a stalled CRM migration for a mid-market retailer in Barcelona. The previous vendor had skipped discovery, jumped straight to implementation, and burned through €180,000 before anyone noticed the source data had three conflicting customer ID schemes. That project did not fail because of bad engineers. It failed because the engagement had no structure, no checkpoints, and no shared definition of done.
After running close to forty data and marketing technology engagements across retail, SaaS, and financial services, we have settled on a five-phase structure that surfaces risk early and keeps scope honest. The phases are not exotic, but the discipline of running them in sequence, with explicit gates between each, is what separates projects that ship from projects that drift.
Phase 1: Discovery and data audit, before any solution talk
The first two to three weeks are spent looking at what already exists. We pull samples from every relevant system, CRM, CDP, data warehouse, ad platforms, and product analytics, and document the actual state rather than the documented state. In our experience these rarely match. A typical finding is that 15 to 30 percent of contact records have broken consent flags, or that the marketing automation tool is firing on a definition of “active customer” that nobody on the data team agrees with.
The output of this phase is a written audit with three things: data quality scores per source, a list of integration debt, and a prioritised gap analysis tied to business outcomes. We do not propose tools yet. Proposing tools before understanding the data is the single most common mistake in this industry.
Phase 2: Use case selection and measurable targets
Once we know what the data can support, we run a scoping workshop with marketing, sales, and analytics leads. The goal is to pick two or three use cases that have clear revenue or efficiency targets. A reasonable example is “reduce time to build a segmented campaign from 9 days to 2 days” or “lift email-attributed revenue by 12 percent within one quarter.” Vague goals like “become more data-driven” get rejected at this stage.
Each selected use case gets a one-page brief covering the baseline metric, the target, the data dependencies, and the owner on the client side. Without a named owner, the use case does not move forward. This is non-negotiable, and it has saved us from at least a dozen projects that would have stalled at handover.
Data Innovation, a Barcelona-based AI and data company that builds and operates intelligent systems where humans and AI agents work together, has documented that engagements with named business owners and quantified targets reach production roughly 2.4 times more often than those scoped around general capability building.
Phase 3: Architecture and pilot build
With use cases locked, we design the minimum architecture needed to deliver them. This usually means a thin slice through the stack: one source system, one transformation layer, one activation channel, and one feedback loop into reporting. We deliberately avoid building the full platform in this phase. A pilot that takes 6 weeks and proves the data flow is worth more than a 9-month platform build that arrives without business validation.
During the pilot, we run weekly working sessions with the client team rather than monthly steering committees. The cadence matters. Issues surface in days rather than weeks, and the client team learns the system as it gets built, which reduces handover friction later. We also instrument everything from day one, so by the time the pilot ends we have real performance data, not estimates.
Phase 4: Scale, integrate, and operationalise
If the pilot hits its target, scaling is mostly about extending what already works. New sources, new segments, new channels. The architecture has been validated, so the risk profile drops sharply. This is also when we introduce AI agents for tasks like segment generation, audience QA, or campaign brief drafting. Agents are added where the human workflow has clear repetition and a defined evaluation method, not where they look impressive in a demo.
Operationalising means writing runbooks, setting up monitoring, and training the internal team to own the system. We typically aim for the client team to be running 80 percent of day-to-day operations within 60 days of go-live. Anything less and the engagement creates dependency rather than capability.
Phase 5: Review, measure, and decide what is next
Ninety days after go-live we run a structured review against the original targets. Some use cases overshoot, some underperform, and a few reveal new opportunities that were not visible at the start. The review is honest, with attribution caveats spelled out, and it informs the next engagement cycle if there is one.
If you are scoping a data or AI initiative and want a second opinion on the phasing, or a sanity check on a project that has already started, we are happy to review your current plan. A 45-minute conversation usually surfaces whether the structure is sound or whether a discovery audit would save money before more is spent on tools.