Picture the CEO in a year-end review: $258k in cost overruns the client wouldn’t pay for. The engineering director says the team keeps missing handoff deadlines. Someone in procurement says the BOM they’re working from is never current. Everyone agrees there’s a problem. When someone asks for examples — real incidents, with cost and schedule data attached — the request goes into the organization and comes back weeks later. Four weeks, sometimes six, sometimes ten. And what comes back isn’t cost. Not schedule impact. A list of client-driven changes, a lot of churn. The churn is real, but it doesn’t document what the problem is worth solving or which part of the workflow is actually breaking.
That’s the first way requirements alignment fails: leadership knows the problem, but the organization can’t document what it costs.
The second way: you get everyone in the room, and there are four or five competing diagnoses. The engineering director thinks the problem is procurement process. The procurement lead thinks it’s engineering data quality. Project controls thinks it’s milestone definition. Everyone is partially right. The session becomes a persuasion contest. Whether one viewpoint wins depends on personality and seniority, not evidence. Leadership leaves with a list of conflicting priorities and no way to rank them.
Both failures have the same result. The integration project starts late, narrows in scope too early, or drifts into scope creep once the work begins, because nobody agreed on what the work was actually for.
A requirements review that sticks runs three tiers in sequence. Tier 1 is strategic direction: what problem the organization is aligned on solving and what it’s worth. Tier 2 is workflow capture: how work actually moves between disciplines before the integration touches it. Tier 3 is field mapping: what data needs to exist where, and in what format. Most integration projects start at Tier 3. That’s why most of them drift.
This post covers:
- Why the evidence gap and the competing priorities problem prevent teams from ever leaving Tier 1
- How a rose-bud-thorn workshop produces alignment in two hours instead of six weeks
- What workflow capture is and why it has to precede field mapping
- The three workflows every EPC data integration needs before Tier 3 begins
Why Requirements Alignment Fails Before It Starts
When an engineering director says the data handoff is broken, the diagnosis is correct. The problem is that “broken” is a diagnosis, not a requirement. To build an integration that fixes the right thing, you need to know what broken costs: in dollars, in schedule, in expediting fees, in rework. Your firm probably can’t produce that number on short notice, if at all.
The request goes out. The organization looks for examples. What comes back is churn: a record of changes driven by the client, a list of back-and-forth. There’s a real problem buried in that churn. But the connection between the churn and the business impact is missing. Leadership sees a problem. Nobody can prove what it costs.
Until you close that gap, every requirements session produces opinion, not evidence. And opinion-based sessions produce the second failure: the competing priorities room.
Four or five people each arrive with a diagnosis. They spend the session trying to persuade each other. Organizational behavior researchers call this the HiPPO effect: the Highest Paid Person’s Opinion carries the day, not because it’s most accurate, but because authority bias is real and teams follow the senior voice. Leadership leaves with conflicting priorities and no mechanism to choose between them.
Tier 1: Strategic Direction
Before any integration requirements are defined, run a rose-bud-thorn session. The method comes from the LUMA Institute, a human-centered design practice used by firms ranging from startups to the Fortune 500.
The format is simple. You identify one problem statement to anchor the session — a single question the executive team has agreed to bring into the room. Then every participant spends fifteen to thirty minutes writing quietly: the roses (what’s working), the thorns (what’s broken), and the buds (what the opportunity looks like if the thorn is fixed).
Nobody talks during that period. Nobody persuades. Nobody’s viewpoint gets crowded out by a more senior voice or a more confident presenter. This is the same mechanism behind what organizational researchers call brainwriting: written ideation produces more ideas and higher-quality ideas than open verbal discussion, precisely because it eliminates the dominance effect that makes most meetings unproductive.
Then you collect the outputs, read them aloud, and collate them into themes. Procurement’s thorns land next to engineering’s thorns. Project controls’ buds sit next to the client’s buds. Patterns emerge that no single person in the room would have articulated on their own.
Then you prioritize. As a group, you rank the themes. The priorities that come out of that ranking reflect the whole room, not the loudest voice in it.
In one to two hours, the group has heard every participant. Everyone understands each other’s viewpoint. The leadership team has a prioritized list of what the organization believes matters most. They have the standing to say: we’ve heard the input, here’s the direction, let’s get behind it.
That’s the alignment that a requirements process is supposed to produce. Most skip the structure that makes it possible.
Tier 2: Workflow Capture
Strategic direction is not a requirements document. Once priorities are set, the next step is workflow capture. Most integration projects skip this too. In EPC capital project management, this phase is called Front-End Loading (FEL), the established practice of locking scope definition before detailed engineering begins. Research on capital projects shows that nearly three-quarters of oil and gas projects overrun their initial budgets by more than 25%, and inadequate front-end scope definition is the primary cause. Data integration projects have the same failure mode.
What your integration project starts with instead is a list of fields. “We need the line number to show up in the ERP.” “We need the pipe spec to flow through to the procurement platform.” Fields are necessary. But fields without a workflow are like a parts list without assembly instructions.
Workflow capture starts with the primary workflow: what actually happens when a P&ID gets issued and purchasing identifies changes? Who touches it? In what sequence? What data does each person need, and in which system? Map that process end to end before you define a single field.
Then the secondary workflow: a design change comes in two weeks after the original issuance. How does purchasing respond? What triggers the update? How does the changed data get back to the right person in the right system?
Then the third workflow: a purchase order has been issued. How does that PO information flow back to the design? Who reconciles it? What happens to the model when the vendor delivers something different from what was specified?
These three workflows define the actual data requirements for your integration. Field mapping follows from them. Integration scope follows from them. Without them, the integration starts with the right intentions and expands into scope creep because nobody defined what done looks like.
Tier 3: Field Mapping
Field mapping is probably where your last integration project began. It’s also the only tier where the work is fully visible to outside stakeholders, which is part of why it gets prioritized. You can put a field mapping spreadsheet in a room and everyone understands what they’re looking at.
The problem is that a field map built without Tier 1 and Tier 2 in place is a list of guesses. Which fields matter depends on which workflows they serve. Which workflows matter depends on which problem the organization agreed to solve. Skip the upstream tiers and the field map expands indefinitely, because there’s no bounded scope to constrain it.
When Tier 1 and Tier 2 are done first, Tier 3 becomes straightforward. The workflows tell you which data objects need to move, in what direction, and when. The field map is an output of that analysis, not a substitute for it.
What This Sequence Produces
Tier 1 gives leadership a defensible strategic direction. Tier 2 gives the integration team a bounded scope. Tier 3, run in that order, produces a field map that every stakeholder can trace back to a business problem.
Without that sequence, integrations become tedious and drawn out. Requirements surface as the work progresses. Scope expands without a filter. The original business problem gets buried under a list of field mappings that nobody can connect back to a cost or a schedule impact.
With it, leadership can point to the priority the organization committed to, the workflows that define the scope, and the field map that follows from both.
That’s what a requirements process that sticks actually produces.