The AI vendor arrives with a demo. The demo works perfectly. The board is excited. The initiative is funded. The data team is handed a deadline.
Three months later, the initiative has stalled. The model works, but the outputs are useless. The input data has duplicates, inconsistent hierarchies, and revenue figures that do not match finance. The board asks the data team what went wrong.
The data team did not create the three ERPs that do not agree. Nobody funded the infrastructure. Nobody gave them authority over source systems. Nobody asked them to reconcile anything before the AI vendor showed up.
They inherited the org chart’s dysfunction and got handed a deadline.
The question nobody asks
When an initiative stalls because of data, the reflexive question is “why is the data bad?” The useful question is “what data is this using, and who decided that was good enough?”
The difference matters. The first question assigns blame to the team responsible for data. The second question investigates the decision chain that led to the initiative being built on an unreliable foundation.
In most portfolio companies, the decision chain looks like this.
The operating partner identifies a value creation opportunity. The management team agrees. A vendor or internal champion proposes a solution. The solution is scoped and budgeted. The data requirements are mentioned in passing as a line item. Nobody validates whether the requirements can be met with the current infrastructure. The project launches.
Somewhere between the proposal and the launch, someone assumed the data was ready. That assumption was never tested. It was embedded in the project plan as a dependency that nobody owned.
When the initiative stalls, the assumption surfaces. But by then, the budget has been spent, the timeline has been consumed, and someone needs to be accountable. The data team is the easiest target because they are the ones holding the broken data when the music stops.
How the data team inherits the dysfunction
The typical data team in a mid-market portfolio company is small. Two to five people. They are responsible for reporting, analytics, dashboard maintenance, and ad hoc requests from leadership. They did not design the systems they work with. They did not choose the ERP. They did not set the data definitions. They did not make the decision to run three different platforms that do not share a common customer ID.
They inherited all of it.
The CRM was implemented by the sales team four years ago. Customer records were entered manually with no validation rules. 30% of the records are duplicates. The data team knows this. They raised it once and were told it was not a priority.
The ERP was implemented during the last ownership period. The chart of accounts was designed for a different business model. Revenue recognition follows a methodology that the current CFO disagrees with but has not changed because the migration would be too disruptive. The data team works around it.
The third system is the billing platform. It has its own customer records, its own product taxonomy, and its own definition of revenue. It was implemented by the finance team during an add-on integration. The data team was not consulted on the implementation. They were handed the task of making the billing data reconcile to the ERP. It does not reconcile. They produce a monthly adjustment.
Layer these systems on top of each other and you get the data environment the team operates in. No common customer ID. No agreed-upon revenue definition. No single source of truth for any metric the board tracks. And a mandate to produce accurate reports from this environment every month.
The data team did not create this. They are maintaining it. And when an AI initiative requires clean, consistent, reliable input data, they are the ones who have to explain that it does not exist.
The authority gap
The core issue is not competence. It is authority.
The data team can identify that the CRM has 30% duplicates. They do not have the authority to enforce data entry standards on the sales team. They can propose it. They cannot mandate it.
The data team can identify that the ERP revenue recognition methodology is inconsistent. They do not have the authority to change the chart of accounts. That decision sits with the CFO and requires executive alignment that has not been achieved.
The data team can identify that the billing platform uses a different customer taxonomy than the CRM. They do not have the authority to standardize the taxonomy across both systems. That decision affects operations, finance, and sales. It requires a cross-functional mandate that nobody has given them.
Without authority over the source systems that generate the data, the data team can only work downstream. They can clean the data after it has been produced. They can reconcile discrepancies. They can build workarounds. But they cannot prevent the data quality issues from occurring in the first place.
This is like asking the CFO to produce accurate financials while denying them authority over the chart of accounts. The task is structurally impossible. But the data team absorbs the blame when the outputs are wrong because they are the last hands on the data before it reaches leadership.
What the data team actually needs
The fix is not a bigger data team. It is not better tools. It is not a data lake or a cloud migration or a new BI platform.
The data team needs three things that cost nothing in technology and everything in organizational will.
Decisions about what is canonical. For every metric the board tracks, someone needs to decide which system is authoritative. Revenue comes from here. Customer count comes from here. When two systems disagree, this one wins. These decisions are uncomfortable because they require leadership to take a position. But without them, the data team spends their time reconciling rather than analyzing.
Authority to enforce standards at the source. If the CRM is the authoritative customer system, the data team needs the authority to enforce data entry standards. Required fields. Validation rules. Deduplication processes. Without this authority, the team spends 40% of their time cleaning data that should never have been dirty.
A mandate that precedes the initiative. Data readiness should be assessed and addressed before the AI initiative launches, before the pricing optimization project kicks off, before the new reporting platform is selected. The data team should be part of the scoping conversation, not the cleanup crew after the initiative fails.
The pattern across twenty years
I have spent twenty years in data environments, from Fortune 100 to mid-market portfolio companies. The pattern is identical at every scale.
An organization makes technology decisions without consulting the people who will manage the data. Decisions are made in sequence rather than in coordination. Sales picks a CRM. Finance picks an ERP. Operations picks a billing platform. Each decision is reasonable in isolation. Nobody owns the intersection.
The data team is hired or assembled after the systems are in place. They inherit an environment they did not design. They are measured on the outputs of systems they do not control.
When the outputs are wrong, they are blamed.
This is not a mid-market PE problem. It is an organizational design problem. But it is particularly acute in PE-backed companies because the timeline is compressed. A Fortune 100 company can absorb five years of data dysfunction and eventually fund the fix. A PE-backed company on a five-year hold with 10-12% required EBITDA growth cannot afford a single wasted year.
What the operating partner can do
The operating partner is in a unique position to break this pattern because they sit outside the organizational dynamics that created it.
Ask the right question first. Before any initiative that depends on data, ask “what data is this using, and is that data reliable?” Not after the initiative stalls. Before it launches. The data team will tell you the truth because you are not the person who chose the systems and you are not the person whose bonus depends on the numbers looking good.
Fund the infrastructure, not just the initiative. When the value creation plan calls for pricing optimization, the budget should include the data work required to make pricing optimization possible. If the cost data lives in three systems that do not agree, the budget should include the reconciliation work. Funding the initiative without funding the foundation is funding the failure.
Give the data team a seat at the table. When the board discusses the value creation plan, the data team should be in the room. Not to present dashboards. To validate whether the data can support the initiatives. If the plan calls for customer segmentation analysis and the CRM has 30% duplicates, that is information the board needs before committing to the plan.
Assign accountability to the decision, not the execution. When an initiative stalls because the data was not ready, the accountability should trace back to the decision to launch without validating the data, not to the team that flagged the data issues and was told to proceed anyway.
The reframe
The data team is not the problem. The data team is the diagnostic.
If your data team is spending 60% of their time reconciling, cleaning, and working around source system issues, that tells you the organization has not invested in the infrastructure those systems require. The team’s behavior is a rational response to the environment they were placed in.
The fix is to change the environment. Make the decisions that create clarity. Fund the infrastructure that makes the data reliable at the source. Give the team the authority they need to maintain quality, not just to report it.
In a market where 12 is the new 5 and every operational improvement depends on data, the companies that treat their data team as a strategic function will outperform the ones that treat them as a cleanup crew.
The data team already knows what is broken. They have known for years. The question is whether the organization is ready to listen and act. Because in this market, the cost of not listening shows up in diligence, in multiples, and in the exit that takes two years longer than it should have.