The Law Doesn’t Lie: How I Settled a Government ERP Dispute With a Workshop

Disclaimer: The views and opinions expressed in this article are those of the author and may not reflect the perspectives of IIBA.

This is the first entry in IIBA's 2026 Analyst Catalyst Blog Contest, “The Knowledge That Changed the Conversation,” part of the Enabling Confidence initiative. If this one resonates, vote for it in our LinkedIn poll at the end of the contest.

There’s a specific kind of pressure when, in a government ERP (Enterprise Resource Planning) implementation, the client uses the word “inaccurate” to describe your system. It doesn’t matter how clean your test cycles were or how carefully the solution was configured. The moment a stakeholder group points at a number and says, “your system is wrong,” the project stops moving forward.

That is exactly where I found myself during parallel testing for a federal government institution in Mexico. The discrepancy was small: minor differences in two payroll calculations. But it was being used as the primary argument against the new system. And in a government environment, with all the institutional weight that comes with it, small discrepancies don’t stay small.

Neither a persuasive argument nor a technical fix changed the room, but a workshop did—one built around a single principle: when two parties disagree about what’s correct, stop arguing about the systems and go back to the authoritative source both sides are legally bound to follow.

The Problem That Wouldn’t Stay Technical

The project was an Odoo ERP implementation for a federal government financial agency in Mexico. Government projects carry their own dynamics—accumulated institutional processes, a workforce accustomed to legacy systems, and layers of organizational politics underneath every decision. Government change runs deeper than operations.

We were in the final pre-go-live validation phase, known as parallel testing: both the legacy system and the new Odoo implementation processing the same data simultaneously. This wasn’t a simulation. The client provided actual employee records, real salary figures, and live payroll inputs so that both systems could produce results under identical and real conditions. The logic is straightforward: if both systems process the same data and return the same outputs, the migration is ready to move forward. If they diverge, you need to understand exactly why before anyone cuts over.

They diverged.

The discrepancies were in payroll, specifically in ISR calculations (Impuesto Sobre la Renta, Mexico’s federal income tax withheld from wages) and IMSS quotas (the social security contributions mandatory for employees and employer). These aren’t simple or flat-rate deductions. ISR follows sliding-scale rate tables published by Mexico’s tax authority. IMSS contributions follow precise statutory formulas defined in the Social Security Law.¹ 

Every decimal matters, and small errors compound across an entire workforce.
The client’s position was unambiguous: the difference in results proved that Odoo was calculating incorrectly. This wasn’t a quiet concern raised in a status note. It was becoming the central argument against accepting the system.

Before the Workshop: Managing the Tension Deliberately

I want to be direct about this part, because I think it gets skipped over at the end of projects: the first challenge wasn’t analytical but relational.

When there’s significant tension between an implementation team and a stakeholder group, walking in and saying, “actually, you’re wrong” (even with solid evidence) rarely resolves anything. It tends to harden positions rather than open them. That’s especially true in a government context, where the stakes of being found wrong extend beyond the project itself.

So my first move was internal. I walked my team through my analysis of where I believed the discrepancy was originating, and we tested the logic together before approaching the client. The internal alignment was about making sure that when we did bring the finding forward, we did so with a shared position we had tested together before walking into the client's room.

Once we were aligned, I described a workshop: a session in which both sides would arrive at the answer together, from a source that neither party had authored. This comes from a principle I’ve come to rely on in high-stakes business analysis work: in a dispute over what’s correct, the most effective position you can create is one where the truth surfaces in front of everyone at the same time, from a neutral source.

It removes the adversarial dynamic; it’s no longer your system against theirs. It’s both of you, following the same rules and reaching the same result.

A Guide to the Business Analysis Body of Knowledge (BABOK Guide) describes this kind of structured collaborative session under elicitation and collaboration techniques. In practice, it means doing the preparation work to make the session possible—which, in this case, was significant.

The Workshop: The Moment the Room Shifted

I gathered every official artefact required to perform the payroll calculations manually: the SAT's income tax rate tables, the IMSS integration salary factor formula, and the applicable statutory percentages for both employer and employee contributions. All are publicly available and legally binding on both parties equally.

The session brought together payroll staff from the client's side and our implementation team. We began by calculating manually, both teams working from the same official documents, step by step, before any system comparison was made. The sequencing was intentional. By validating that our manual calculations matched each other first, we established a legally grounded baseline that both sides had built together. Any discrepancy between that baseline and a system output would be a system problem, with no room left for interpretation.
Odoo matched the manual calculation.

The legacy system did not.

The room went quiet. In a government context, a finding like that doesn’t land cleanly—if the legacy system had been calculating incorrectly, that meant people inside the organization had been responsible for a process running with a built-in error. There was a silence that wasn’t exactly acceptance. It was more like the absence of a counterargument. And in a room that had been full of counterarguments, that silence was the shift.

Conclusion: What Business Analysis Looks Like in Government

Over the weeks that followed, the conversation changed. The client began to look at the legacy system differently. The discrepancy hadn’t appeared randomly. It existed because the payroll process required human intervention at multiple steps, and that intervention had introduced the error over time. The discussion moved from "your system is imprecise" to "our process has too many manual steps."

That realization became an argument for migration, not against it. The project continued, and resistance from leadership decreased. One detail from my experience still stays with me: some of the end users (the people farthest from the executive tensions) started asking when they could access Odoo in the UAT environment. They found it more intuitive than what they had been using. They wanted to start.

Business analysis in government isn’t primarily a technical challenge. The work we did in that workshop—tracing a discrepancy to its root cause, building a session structure around legal artefacts, managing the internal dynamics before presenting a finding to the client—that’s what the BABOK Guide describes as the intersection of root cause analysis, structured elicitation, and stakeholder collaboration. And it was applied in a sector where business analysis is rarely recognized by name.

The answer to "what did you know that changed the room" goes beyond the ISR formula: in conditions of uncertainty and political pressure, the most effective thing a business analysis professional can do is design the conditions in which the truth can be discovered together, rather than delivered by one side to the other.

That is the skill. That is what changed the room.

¹IMSS (Instituto Mexicano del Seguro Social). Quota formulas and statutory percentages are defined in the Ley del Seguro Social at https://www.imss.gob.mx.

---

About the Author