In my previous role, the IT team and the operations director both wanted different things from a new reporting system. I organised a joint workshop, mapped each team's core needs against the project objectives, and found requirements that satisfied both sides without delaying delivery. The project launched on time and both teams rated the solution highly in the post-launch review.

I noticed our month-end reporting was consistently taking three days when it should have taken one. I mapped the as-is process and found data being manually copied between four systems with no validation. I proposed an automated extract, built a business case, and worked with IT to deliver it in two sprints. Reporting time dropped from three days to four hours.

I had to present a data migration plan to senior managers with no technical background. I avoided all jargon and used a house-move analogy — we were moving everything from one house to another, some things needed careful packing, some things we'd leave behind. They approved the plan in the meeting and the migration completed without business disruption.

Midway through a sprint we discovered a key assumption in our requirements was wrong — the legacy system couldn't export the data we'd built around. I flagged it immediately, got the right people together, and we re-scoped to work around the constraint. We delivered a reduced scope on time, with the full feature in the following release. I learned to validate technical assumptions much earlier in discovery.

The steering committee wanted to cut user acceptance testing to save time. I didn't have authority to block the decision, but I put together a short risk paper showing three recent examples where skipping UAT had caused expensive post-go-live fixes. They agreed to keep a reduced UAT window. The system launched with no major defects.

I start by confirming who needs to be in the room and circulating a clear agenda in advance. On the day I run a structured session — as-is walkthrough, gap analysis, future-state mapping. I use dot voting or MoSCoW to prioritise. I document outputs in real time and circulate a summary for sign-off within 24 hours.

Functional requirements describe what a system must do — for example, a user must be able to reset their password by email. Non-functional requirements describe how well it must do it — response time under two seconds, 99.9 per cent uptime, WCAG 2.1 accessibility. Non-functional requirements are the most commonly missed, and that's usually where production systems fail.

I use a requirements traceability matrix to make sure every business objective maps to at least one requirement and each requirement links to a test case. Before sign-off I walk stakeholders through the requirements in plain language rather than just sending a document. I make sure the right people sign — the business owner, not just the project manager.

In Agile, the BA role is iterative and embedded. Rather than producing a large upfront specification, I'm constantly refining the backlog, writing and grooming user stories with the team, and available to answer questions mid-sprint. In waterfall I'd spend more time upfront and hand off a formal specification. Both have their place depending on the project.

From my research, Hartley is a well-established financial services firm investing significantly in digital transformation — exactly where a BA adds most value. I'm particularly interested in how the business is modernising its customer-facing processes, an area I have direct experience in. I'd want to verify the specifics with you today, but that's what made this role stand out.

I see regulation as a constraint to design around rather than a blocker. In financial services, the most useful thing a BA can do is understand the regulatory intent behind a rule, not just the rule itself — that way you write requirements that are genuinely compliant rather than technically meeting the letter of policy. I always involve compliance and legal early in discovery, not at the end.

I invest time early in building relationships before there's pressure on the project. I make sure I understand each team's priorities and constraints, not just what they need from me. I communicate proactively — short, regular updates rather than big formal reports — and I'm honest when things change. That trust pays dividends when things get difficult later.

I'd ask them to walk me through exactly why — 'impossible' often means 'not with our current stack'. Once I understood the constraint, I'd go back to the business stakeholder with the options: do without, find an alternative approach, or accept a longer timeline. My job is to make sure the decision is an informed one.

First I'd listen — separately, to the key stakeholders before suggesting anything. You need to understand the different versions of what went wrong before you can help. Then I'd work to get a shared baseline: what are we actually delivering, who owns the decisions, and what are the real constraints. Once there's a shared picture, you can start making progress.

I'd start by understanding why — too busy, unclear on what's needed, or disengaged from the project. If it's time, I'd reduce the ask — a 15-minute async review rather than a two-hour meeting. If it's engagement, I'd help them understand the risk of not being involved. If it persists, I'd involve the project sponsor to make escalation a business decision, not a personal one.

I'd document exactly what's changed and the impact — on the business case, scope, and timeline. Then I'd present the options clearly to the project sponsor: continue and accept reduced return, re-scope to something still viable, or stop the project. My job isn't to hide bad news — it's to make sure the right people have the right information to make the right call.