Paradigm has spent enough time in data programs to know that most problems don’t start during testing or after go-live. They start during or even before kickoff.
Everyone is moving quickly. Workshops are happening. Requirements are coming together. Architects are drawing future-state diagrams. The team feels like it’s making progress.
Then six months later someone realizes the definition everyone thought was agreed upon wasn’t actually agreed upon. A critical business process lives outside the system. A future initiative wasn’t considered during design. Or nobody can answer who owns a decision when priorities conflict.
At that point, technology isn’t the problem, the organization is.
That’s why we spend a lot of time challenging assumptions before our teams start building.
We Never Assume Governance is as Mature as People Think it is
Almost every organization tells us they have governance and the truth is, most do.
The problem is that governance often looks much stronger in a PowerPoint deck than it does when real decisions need to be made. We’ve seen this firsthand in recent PIM and data governance initiatives.
On paper, ownership was straightforward. Different teams had defined responsibilities. There were steering committees, standards, and documented processes. But, once we started discussing product content, attachments, dependencies, future capabilities, and regional requirements we found that the answers changed depending on who was in the room.
That isn’t a governance document problem. It’s a decision-making problem.
In a Fabric environment, contradictory definitions quickly become visible because data products, reports, and AI solutions are all consuming the same information. Informatica then operationalizes these definitions through integration and governance processes. If teams aren’t aligned before kickoff, the platform exposes the problems almost immediately.
That’s why one of our first questions is always: “Who makes this decision if two stakeholders disagree?”
If nobody can answer that question quickly, we usually have more work to do before we can start building.
The Real Process Almost Never Matches the Architecture Diagram
The architecture diagram is usually the easy part. Understanding how the business works is much harder.
We can’t count how many times we’ve walked into a project believing a process was handled by a system only to find out part of the process lives in a spreadsheet, part lives in someone’s inbox, and part depends on a conversation between two teams every Friday morning.
The biggest dependencies are often outside the project scope.
A recent example comes from a global manufacturing program where we are implementing a Local Parts solution. On paper, the team was focused on Local Parts, but Adobe was responsible for part of the customer experience. That meant Adobe had to be considered in design discussions, even though it wasn’t officially part of the project scope. Whether a dependency appears on a project plan doesn’t matter. If it affects the outcome, it’s a dependency.
The same thing happens with future initiatives. A project team can focus on Local Parts today, but if Reference Management is coming next, we need to understand how today’s decisions affect tomorrow’s solution. Otherwise, we’re designing an MVP that we already know we’ll need to redesign later.
The Biggest Data Problems Usually Haven’t Been Found Yet
Most organizations know where they have bad data. They know which fields are incomplete. They know where duplicate records exist. Those aren’t usually the issues that cause the most pain. The bigger problems are the ones nobody sees because the systems haven’t been forced to work together yet.
What happens in workshops is predictable. Someone asks how Local Parts content will coexist with larger global content. Another person asks how supersessions will work once parts are replaced. A third person asks how future Reference Management capabilities fit into the model. Then the room gets quiet. Not because we don’t have the right people in the room, but instead because nobody has needed to answer those questions before.
Those discussions aren’t about data quality. They’re business decisions. If these decisions aren’t made early, they eventually become data quality issues, reconciliation issues, and trust issues. We’ve seen organizations spend months fixing problems that could have been avoided with one uncomfortable conversation during discovery.
Performance Problems Usually Start During Design
One of the most expensive mistakes we see is treating performance as a future concern.
Teams often assume they can optimize later and sometimes they can, but most of the time they can’t.
By the time a solution reaches testing, many of the decisions that affect performance have already been made. Data movement patterns are established. Integration approaches are selected. Workflows are defined. The architecture is largely set.
Changing those decisions later is significantly harder than challenging them during design.
We’ve seen teams spend weeks troubleshooting symptoms that were created by choices everyone agreed to months earlier. It’s much easier to challenge an assumption on a whiteboard than inside a production environment.
That’s why we push these conversations early, even when everyone is eager to start building.
The Biggest Risk is Almost Never Technology
Across the programs we’ve delivered, we’ve yet to see a project struggle because Informatica or Fabric couldn’t do the job.
We’ve seen plenty of projects struggle because the organization wasn’t aligned on what it was trying to accomplish.
Before kickoff, we push every client to answer five questions:
- Who owns the platform?
- Who approves changes?
- Who sets priorities?
- Who resolves conflicts?
- Who is accountable when something goes wrong?
Those are leadership questions, not technology decisions. The projects that move smoothly aren’t necessarily the ones with the best technology. They’re the ones that address these questions before the build starts.
Why We Push on These Things So Early
Clients sometimes think we’re slowing things down when we challenge assumptions during kickoff. We are – because we’re trying to avoid the conversations we’ve had to facilitate six months later, after requirements have been approved, integrations have been built, and changing direction becomes expensive.
The conversations where teams realize a dependency wasn’t understood, ownership wasn’t clear, or one where everyone discovers they were working from different assumptions.
Paradigm has been through enough programs to know that those issues don’t get cheaper with time. They get buried, then resurface as rework, delays, escalation calls, and missed expectations. We’ve learned to challenge these assumptions early because we’ve seen what happens when they go unchallenged.
By Brandy Riley, Project Manager