01
Starting point
It was not clear what the supplier was delivering, what had actually been completed, what could be accepted or paid for, and who was holding up approval.
Case study · Delivery diagnosis
Supplier delivery flow diagnosis and redesign
In a regulated financial environment, it was not clear enough what the supplier was delivering and when. The solution was not to introduce a new tool, but to reorganise how the existing Jira and Confluence setup was used.
In short
The problem was not only on the supplier side.
On the surface, it looked like supplier delivery uncertainty. During the diagnosis it became clear that internal information flow, approval and tool usage also failed to provide a clear enough delivery picture.
02
Real problem
Oversized requirements, parallel Jira tickets, manually maintained Confluence tables, unclear statuses and missing ownership.
03
Proposed solution
Smaller stories, clearer Jira boards, a Confluence structure based on Page Properties, subtask-based approval and a structured supplier release note.
Context
Joining halfway through requires a different type of work.
The project was already running, the ways of working had taken shape, and stakeholders were following existing habits. In this situation, the realistic goal is not to rebuild everything, but to quickly understand where delivery gets stuck, where decisions are not visible, and which administration only appears to hold the process together.
The goal of the diagnosis was to get more usable information from the existing Jira and Confluence environment — without a new licence, a new system or a major organisational change.
The question was not whether Jira and Confluence existed. It was whether they showed the real state of delivery.
Diagnosis
Three questions for each area: what happens now, why is it a problem, and what is the recommendation?
This case study follows the logic of the actual diagnosis: it does not start with generic advice, but with the points where the current way of working created delivery risk and what was worth changing first.
Jira setup
Jira was already in use, but the ticket structure did not reflect actual deliverability. Because of large business requirements and parallel internal / supplier tickets, it was difficult to tell what had really been completed.
Current setup
- one large business requirement typically had one large Jira ticket;
- internal and supplier-related tasks were split across two separate Jira spaces, even though they belonged to the same delivery flow;
- internal team members moved statuses based on the supplier release note;
- bugs appeared in multiple places, not always with a traceable source.
Why is this a problem?
- it is not visible whether a large requirement is fully complete or only partially done;
- status administration does not happen where the actual delivery work takes place;
- duplicate bugs and parallel tickets increase noise;
- the project does not get a clear picture of what can be tested and accepted.
Recommendation
- business requirements of the current size should be represented as epics;
- smaller stories that can be developed and tested independently should sit under the epic;
- supplier tickets should be connected to a scrum board and a short sprint logic;
- bugs should be traceable by label;
- internal and external bug handling should happen on one board where possible, with clear owners.
Confluence setup
A lot of information was available in Confluence, but across too many pages, language versions and manually maintained collection tables. As a result, documentation increased the tracking effort instead of reducing it.
Current setup
- business requirements were split across several subpages, with separate Hungarian and English versions;
- approvers were shown at the top of pages using checkboxes and @mentions;
- multiple manual tables collected the same requirement links and status data;
- changes were marked with colours, but it was not always clear whether they happened before or after approval.
Why is this a problem?
- the same information had to be updated manually in multiple places;
- a checkbox is not a real workflow: it does not show who responded, who asked a question or who is blocking progress;
- approval status often had to be reconstructed from emails or conversations;
- later changes could reopen already approved content without proper control.
Recommendation
- one business requirement should live on one main page, with the English version on the same page;
- owners and status data should be captured in a Page Properties macro;
- manual collection tables should be replaced by Page Properties Report;
- approvers should receive Jira subtasks instead of checkboxes;
- new requirements / changes after acceptance should be handled as separate changes.
Supplier handover
The supplier worked in its own tool, and changing that was not realistic. The goal was therefore not to introduce a new shared system, but to structure the handover format.
Current setup
- the supplier provided an incomplete release note;
- the internal team had to dig through what was included in a given handover;
- there was no consistent view of what changed, what could be tested and what remained open;
- the supplier did not work in Jira / Confluence, but in its own Notion-based setup.
Why is this a problem?
- interpreting the handover required extra internal effort;
- testing started later because the team first had to clarify what needed to be checked;
- the incomplete release note increased the risk of misunderstanding what was actually done;
- a completely new way of working could not realistically be forced onto the supplier.
Recommendation
- the supplier can stay in its own Notion environment;
- it should receive a structured markdown release note template;
- the template should provide a consistent handover format when exported to PDF;
- the internal team should see more quickly what changed, what can be tested and what needs a decision.
Ownership and approval
Delivery visibility is not only a tooling question. The location of the ball has to be visible: who decides, who responds, and who closes open business and product-side questions.
Current setup
- approvers signalled in multiple places and in different ways;
- it was not always clear whether a tick really meant approval;
- the PM could not always validate the delivery at the necessary business depth;
- there was no assigned product-side owner to keep the requirement together.
Why is this a problem?
- approval status was not reliable decision information;
- it was difficult to see who owned the next step;
- open comments and questions could slip back into later delivery stages;
- business validation of the supplier handover did not have strong enough ownership.
Recommendation
- there should be an assigned PO / owner role per application, even if it rotates;
- approvers should receive tasks through Jira subtasks;
- the owner should only close their own subtask when every approval and open question has been resolved;
- the approval board should show at any time who the process is waiting for.
Summary
The need was not for new software, but for a clearer structure and less manual investigation.
The figures below are partly concrete recommendations and partly target values: the final impact should be measured after two release cycles. The point is that the change was based on better use of existing tools, not on buying new licences.
0 Ft
New software / licence
The recommendation was built on Jira, Confluence and the supplier’s existing Notion environment.
6 → 1
Manual collection tables
Instead of several parallel Confluence tables, a Page Properties Report-based view can provide the overview.
2 → 1
Ticket and bug handling logic
Less duplication and clearer responsibility instead of parallel internal / supplier tracking.
to measure
Administration time
The goal is to reduce daily manual administration and release note investigation; the exact time saving can be measured after implementation.
Suggested measurement points: number of manual updates, approval lead time, ratio of duplicate bugs, time spent interpreting release notes, and whether it is possible to answer on any given day: what has actually been completed?
Follow-up measurement
The impact should be checked after two release cycles.
Because the work was done at diagnosis and recommendation stage, the result should not be overstated. The next step is to try the changes and measure the target values above.
Administration
Does the same information need to be updated in fewer places, and does the time spent interpreting release notes decrease?
Approval
Can it be identified faster who is holding up a business requirement, and is the real approval status visible?
Handover
Are there fewer misunderstood done states, duplicate bugs and internal investigations around handover?
Key takeaway
Delivery is not always slow. Often it is simply not visible enough.
In this situation, the missing piece was not a new tool, but a more traceable operating model. Jira, Confluence and supplier communication already existed, but they did not support the same delivery picture.
The proposed solution was built on existing tools: smaller developable units, a clearer board structure, subtask-based approval, automatically collectable Confluence metadata and clearer ownership.
This is the type of intervention where a major transformation is not needed. What is needed is a precise diagnosis, good questions and a few well-placed structural changes.