The calculation was compliant. The product still fell short.

The conclusion first

The regulatory calculation was correct. The product still left the customer with unnecessary organisational work.

That distinction took 39 usage scenarios, a RACI review and a customer meeting to establish. It also changed the proposed solution: no recalculation, no transfer of tracking responsibility to the customer, and one additional product capability around a document date.

Why recalculation looked reasonable

The customer believed the product did not fully cover the regulation. That was a plausible diagnosis. The system returned a compliant result, yet the customer still lacked what they needed to organise the people involved afterwards. From their position, the regulation appeared unfinished inside the product.

Changing regulatory logic on that basis would have been risky. A complaint can accurately describe an experience without accurately locating its cause. We therefore treated the customer’s 39 scenarios as test cases rather than as 39 separate requirements.

For every scenario, I compared three things: what the regulation required, what the product calculated, and what prevented the customer from completing their operational planning.

What the evidence ruled out

The scenarios did not reveal a missing rule. The existing calculation covered the regulation consistently.

They revealed a required document whose date mattered after the calculation. The customer needed that date to decide when people should be available and how many were required. The product did not make the date sufficiently dependable or visible, so the customer had to compensate through coordination across teams.

This was not evidence that the customer should maintain the date. It was evidence that the product should carry it.

The RACI distinction

RACI is a simple way to separate roles in a piece of work. The Responsible party performs the task. The Accountable party owns the outcome and must be able to confirm that the work has been completed correctly.

In this case, the customer was Accountable, not Responsible for tracking the document date. Asking them to maintain it would have changed the operating model. Hiding it from them made accountability expensive.

The design requirement followed from that boundary: the system should track and expose the date so the customer can plan resources without taking over somebody else’s task.

The resulting decision

Decision record

1. 01

   Do not alter the regulatory calculation

   Evidence

   All 39 scenarios were covered by the existing rules

   Decision makers

   Business Analyst and customer representatives

   How it was checked

   Scenario-by-scenario review against the regulation

2. 02

   Preserve the RACI boundary

   Evidence

   The customer is Accountable but not Responsible for date tracking

   Decision makers

   Customer representatives, Business Analyst and Product Owner

   How it was checked

   Responsibility reviewed explicitly with the customer

3. 03

   Add date tracking and visibility to the product

   Evidence

   The date is required for workforce planning and currently creates coordination cost

   Decision makers

   Product Owner and delivery team

   How it was checked

   Customer confirmed the value; Product Owner approved development

The customer meeting confirmed the revised framing. They did not need a second calculation or a new administrative duty. They needed a reliable planning signal.

The analysis and product decision are complete. The change now sits in the team’s standard prioritisation process.

The product question behind the compliance question

Compliance defines what the system must get right. It does not define how much work a customer should need to do around the result.

The calculation met the regulation. A useful product still had to make that result operable.