Two Stakeholders Disagree: What Should the Business Analyst Do First?

The meeting had been going well until the question of approvals came up.

The operations head wanted every high-value transaction to pass through an additional approval before it could proceed. The finance head disagreed. The proposed control, she argued, would slow down transactions that were already subject to financial checks.

Both had come prepared. Both had reasons for their positions. And neither seemed particularly interested in changing their mind.

The project manager looked towards the business analyst.

“Can you capture both requirements and work out how we can accommodate them?”

It sounded reasonable enough. The analyst could document the two requests, discuss the technical options with the architect and return with a proposal.

But there was a problem. The system could not simply make both requirements true in the same circumstances. One stakeholder wanted an additional control; the other wanted to avoid the delay it would create.

The disagreement was not about how a screen should look or which field should be mandatory. It was about how the business should balance control against speed.

And that was not a decision the development team could make on its own.

The first mistake is trying to solve the conflict too quickly

When two stakeholders disagree, the instinct is often to look for a compromise.

Could the approval be optional? Could it apply only to certain transactions? Could the system route some cases differently?

These may eventually be sensible options. But proposing them before understanding the disagreement can turn the business analyst into a designer of workarounds.

Imagine that the analyst suggests making the approval mandatory only above a certain transaction value. The operations head might agree, but the finance head could point out that value alone does not determine risk. A smaller transaction involving a particular customer or unusual circumstance might require more scrutiny than a larger routine transaction.

The conversation moves from one proposed solution to another, and the meeting ends with more questions than answers.

The difficulty is not a lack of possible solutions. It is that the team has not yet established what each stakeholder is trying to protect.

That is where the analyst should start.

Find out what each stakeholder is really concerned about

The operations head may be responding to a recent incident in which a transaction was processed incorrectly. Perhaps the existing controls failed to catch an exception, and the business now wants additional oversight.

The finance head may be dealing with a different but equally real problem. Perhaps transactions already take too long to process, customers are complaining about delays, or the existing approval structure creates unnecessary manual work.

At first glance, the two requirements appear incompatible.

Look beneath them, however, and the underlying objectives may be easier to reconcile:

• Operations wants to reduce the risk of incorrect or unauthorised transactions.

• Finance wants to prevent unnecessary delays and preserve efficient processing.

• Both want the system to support a reliable business process.

This does not mean that the conflict will disappear. There may still be a genuine trade-off between speed and control. But the discussion has changed.

Instead of debating whether an approval should exist, the stakeholders can examine which transactions need additional scrutiny, what risks the approval is intended to address, and what level of delay is acceptable.

A useful question for each stakeholder is:

“What would go wrong for the business if we did not do it your way?”

The answer often reveals more than another round of arguing about features.

Do not assume that both requirements deserve equal priority

One common response to conflicting requirements is to treat both as equally important and leave the delivery team to find a way to implement them.

That approach avoids an uncomfortable conversation, but it does not resolve the underlying decision.

Requirements can have very different implications. One may be linked to a regulatory obligation, another to a preference, and another to a measurable operational problem. They should not automatically receive equal weight simply because they came from senior stakeholders.

The analyst needs to establish the basis for each requirement.

Is the additional approval legally or contractually mandatory? Is it an internal control introduced after a specific incident? Is the processing delay measurable? Does it affect every transaction or only a small subset? Is there evidence that the proposed change will actually reduce risk?

The answers matter.

If a control is mandatory, the team cannot simply remove it because another stakeholder prefers a faster process. If the control is discretionary, the business may have more room to evaluate alternatives.

Similarly, a claimed efficiency problem should be examined rather than accepted as either fact or exaggeration.

The aim is not to rank stakeholders by seniority. It is to understand the consequences of the competing requirements and identify who has the authority to decide between them.

Bring the disagreement into the open

Once the underlying concerns are understood, the analyst can make the conflict explicit.

A simple comparison is often enough to move the conversation forward.

Decision areaOperations perspectiveFinance perspectivePrimary concernReduce transaction riskAvoid unnecessary delaysDesired outcomeStronger oversightFaster processingPotential benefitFewer control failuresBetter operational efficiencyPotential downsideAdditional approval effortRisk of insufficient oversight if controls are weakenedEvidence to examineIncidents, exceptions, audit findingsProcessing times, delay rates, manual effort

This is not a scoring exercise in which the analyst decides which department wins. It is a way to ensure that everyone is discussing the same decision.

The next step is to identify what information is missing.

Perhaps the business does not know how often the relevant exceptions occur. Perhaps the existing approval process already covers some of the risk. Perhaps the delay is caused by several manual steps rather than the approval itself.

If the disagreement depends on facts that have not been established, gathering those facts may be more productive than holding another meeting.

The analyst should also distinguish between a genuine conflict and a misunderstanding. Sometimes two stakeholders use the same term differently, or one is asking for a mandatory control while the other is objecting only to how it is implemented.

Clarifying the language can resolve some disagreements before they become design decisions.

Explore options without pretending there is always a perfect compromise

With the objectives and constraints understood, the team can consider alternative approaches.

In this scenario, the options might include:

Option 1: Keep the additional approval for every high-value transaction.

This may provide consistent oversight, but it could introduce delays even when the transaction is routine and low risk.

Option 2: Apply the approval only when defined risk conditions are met.

The business could use agreed criteria to identify transactions requiring additional scrutiny. This may reduce unnecessary approvals, but the criteria need to be reliable and defensible.

Option 3: Strengthen existing controls instead of adding another approval.

The business could investigate whether existing validation, segregation of duties, exception reporting or monitoring would address the concern. This would require evidence that the alternatives provide adequate control.

Option 4: Retain the approval but redesign the workflow.

For example, the business could examine whether approvals can be routed more efficiently or whether appropriate delegated authority can reduce avoidable delays.

None of these options should be accepted simply because it sounds like a compromise. Each has costs, dependencies and risks.

The analyst's responsibility is to help the business understand those trade-offs. The business owners and authorised decision-makers remain responsible for making the decisions that fall within their remit.

What if neither stakeholder agrees to compromise?

Sometimes the evidence does not reveal a solution that satisfies everyone.

Operations may continue to insist on the additional control. Finance may continue to argue that the delay is unacceptable. Both may be acting reasonably within their own responsibilities.

At this point, the analyst should stop trying to manufacture agreement.

Instead, the decision needs to move to the appropriate authority, with the relevant evidence and consequences clearly presented.

That does not mean immediately escalating every disagreement to a steering committee. First establish whether the stakeholders can resolve the issue within their existing decision rights. If the conflict crosses departmental boundaries, creates material risk or requires a policy decision, a higher-level decision-maker may be needed.

A useful escalation is not simply:

“Operations wants an approval and Finance does not agree.”

It is closer to:

“We have two competing objectives: reducing the risk of incorrect transactions and avoiding delays to routine processing. The current evidence shows these are the main options, with these consequences and unresolved risks. We need a decision on the acceptable control level and the authority to approve the chosen approach.”

That gives the decision-maker something to decide.

It also protects the delivery team from being held responsible for a business trade-off it was never authorised to make.

The decision must survive beyond the meeting

Suppose the business agrees to introduce risk-based approvals.

The analyst's work is not finished when everyone leaves the room. The decision needs to be translated into requirements that can be implemented and tested.

The team must define the conditions that trigger an approval, who can approve it, what happens when information is missing, how exceptions are handled and which records must be retained.

It should also be clear who owns the criteria and who can authorise changes to them.

The decision should be recorded with its rationale, assumptions, dependencies and any residual risks. This is particularly important when the solution involves regulatory controls, financial transactions or other decisions that may be reviewed later.

Finally, the business should agree how it will evaluate the result. If the objective is to reduce unnecessary delays without weakening controls, the team needs appropriate measures for both. Improving processing speed while increasing control failures would not represent success.

A decision is only useful if the people implementing it understand what was agreed and why.

A practical approach for your next stakeholder conflict

The next time two stakeholders give you opposing requirements, resist the urge to begin with a solution.

Start by asking what each person is trying to achieve and what they are trying to avoid. Establish the evidence behind their concerns. Separate mandatory constraints from preferences. Make the trade-offs visible, and identify who has the authority to resolve the remaining conflict.

Then document the decision, including what was agreed, what was rejected and why.

This may sound like additional work, but it is often less expensive than building around unresolved disagreement. If the conflict is discovered during development or testing, the team may already have invested time in a solution that one of the stakeholders will not accept.

The purpose of business analysis is not to ensure that everyone gets exactly what they asked for. It is to help the business make informed decisions about what it needs, what it can afford, and what consequences it is prepared to accept.

In the opening scenario, the analyst did not need to choose between operations and finance. The first task was to understand what each was protecting. Only then could the team decide how to balance risk and efficiency.

When stakeholders disagree, do not begin by asking how to satisfy both requirements. Begin by asking why each requirement exists—and what the business needs to decide.

Terms of Use