Task Answer Frameworks

Tasks A, B — Stakeholders & Problems

Task A — Stakeholder Analysis

Candidates should produce something resembling a stakeholder grid or influence/interest map. Below are the key stakeholders and what a strong response includes for each.

ICB (Integrated Care Board)

Role: Mandating body, funder, performance overseer. Influence: Very high. Interest: High. Disposition: Supportive but demanding — quarterly reviews create pressure. Strong candidates will note the ICB as a sponsor-level stakeholder, not just an external party.

Programme Director

Role: Programme leadership, political navigation. Influence: Very high. Interest: High. Disposition: Experienced but unavailable — creating a governance gap. Candidates should flag availability as a risk.

Deputy COO (Sponsor)

Role: Nominal sponsor. Influence: High. Interest: Medium (defers to PD). Disposition: Passive — a risk. Strong candidates will flag the tension between nominal and effective sponsorship.

Clinical Directorate Leads

Role: Operational owners of referral pathways. Influence: High. Interest: Medium (supportive but guarded). Disposition: Protective of autonomy. Cardiology is a specific sub-stakeholder — the shadow IT situation makes them both a risk and a potential champion if engaged well.

ICT Department

Role: System delivery, technical authority. Influence: High (gatekeepers). Interest: Medium. Disposition: Under-resourced — risk of deprioritisation. The tension with clinical informatics is a co-stakeholder dynamic candidates should surface.

Clinical Informatics Team

Co-stakeholder to ICT. The unspoken tension between them over system ownership is a governance risk. Strong candidates will name this conflict explicitly.

Admin Teams

Role: Process executors, key data entry point. Influence: Low formally, high operationally. Interest: High (anxiety about redundancy). Disposition: Risk of passive resistance. Essential for process validation — candidates should not overlook them.

Dr Priya Soni / Meadowfield MHPS

Role: Partner organisation CEO. Influence: Medium-high (ICB escalation route). Interest: High. Disposition: Actively concerned and escalating. Her clinical lead's non-response is a relationship risk requiring active management. Strong candidates will identify her as a potential blocker with legitimate grievances.

GP Practices / A&E / Referring Clinicians

External referring stakeholders. Often overlooked. Strong candidates will include them as the source of process variation (fax vs. e-RS) and as users who will be affected by any new system design.

Patients

Often the first to be forgotten and the first thing a strong BA will mention. Should appear on any stakeholder map — not as a person to engage but as the ultimate beneficiary and a legitimate interest group.

Task B — Problem Identification

Candidates should distinguish symptoms from root causes. A strong prioritised list might look like this:

Root Cause #1 — No single referral intake process

Three channels (e-RS, fax, email), no central triage, no unified ownership. This drives almost every downstream problem: data quality, delays, siloed waiting lists. A BA who identifies this as the primary root cause is thinking systemically.

Root Cause #2 — Process ownership is undefined

No single accountable owner for end-to-end referral intake. Each specialty managing locally creates variation and risk. This is also a governance problem, not just a process problem.

Root Cause #3 — Meadowfield integration is a programme blind spot

The merger has not produced integrated processes. MH referrals are invisible to Trust-wide reporting. Dr Soni's escalation signals a relationship problem that will become a delivery blocker if not addressed early.

Symptoms (candidates should categorise these correctly)

22% data quality failure rate — symptom of manual re-keying and no validation
Cardiology shadow IT — symptom of unmet need and slow ICT response
Admin anxiety — symptom of poor change communication, not a root cause
Waiting time breach risk — symptom of all the above

Requirements Analysis — Answer Guide

Task C — Full breakdown for each requirement

Candidates should identify flaws, categorise them, and propose an action. Below is the full facilitator breakdown. Note that REQ-SY-01 is intentionally the strongest requirement.

User Stories

REQ-US-01

The system should allow referrals to be submitted quickly and the admin staff can see them and it needs to work properly and be easy to use.

No "As a / I want / So that" structure
Compound requirement — at least three separate needs in one statement
Vague quality terms: "quickly", "properly", "easy" — all untestable
No acceptance criteria or measurable outcome

→ Action: Decompose into individual user stories. Elicit measurable performance criteria. Return to business for clarification on who "admin staff" refers to specifically.

REQ-US-02

Users need to be able to search.

Missing actor ("users" is too vague), object (search what?), goal, and outcome
No context, no condition, no acceptance criteria
Functionally unusable as a development requirement

→ Action: Reject as written. Conduct elicitation session to understand who needs to search, what they are searching for, why, and what a successful result looks like.

REQ-US-03

As a referral, I want to be processed within two days so that patients are not waiting.

Actor is a referral (an object, not a person) — structurally invalid
Two-day SLA has no qualifying conditions, exceptions, or priority categories
"Patients are not waiting" is not a business outcome — it is a circular aspiration
No trigger or driver defined

→ Action: Rewrite with a human actor (e.g. referral coordinator). Define SLA conditions. Replace outcome with a measurable business benefit (e.g. "so that RTT compliance is maintained").

REQ-US-04

As a user, I want the system to send notifications so that I get them.

"User" is too generic — which user type?
"So that I get them" is entirely circular — provides no business value
No trigger defined (under what conditions should a notification fire?)
No channel specified (email, SMS, in-app, letter?)

→ Action: Rewrite per notification type and per user role. Define triggers, channels, and outcomes for each scenario.

REQ-US-05

The dashboard must display all the information that is needed.

No actor, no user story structure
"All the information that is needed" is entirely unmeasurable and undefined
No acceptance criteria possible without knowing what information is required

→ Action: Reject as written. Conduct requirements workshop with relevant stakeholders to define dashboard data requirements by user role. Convert to multiple user stories.

REQ-US-06

As a doctor, I want everything to be integrated so that it works better.

"Everything" is entirely undefined — which systems? Which workflows?
"Works better" has no baseline and no measurable improvement target
No specific clinical workflow or data need referenced

→ Action: Return to the clinical directorate for specific integration requirements. Map which systems need to exchange what data and why. This likely represents multiple requirements.

System Stories

REQ-SY-01 — ⭐ Strongest requirement in the pack

As a referral coordinator, I want the system to automatically validate referral data on submission so that invalid referrals are flagged before they enter the queue.

✓ Clear actor (referral coordinator)
✓ Clear system behaviour (automatic validation on submission)
✓ Clear business outcome (invalid referrals flagged before queue entry)
⚠ Misclassified — this is a user story, not a system story (written from user's perspective)
⚠ Acceptance criteria still need to be defined (what counts as invalid?)

→ Action: Reclassify as a user story. Add acceptance criteria to define validation rules. Otherwise, retain and develop — this is the best-written requirement in the set. Strong candidates will praise this one.

REQ-SY-02

The system shall do reporting.

Not a system story format — no subject, no specific behaviour, no condition
Completely unactionable as written
No audience, no report type, no frequency, no trigger

→ Action: Reject as written. Elicit specific reporting requirements by user role and business need. Likely to decompose into 5–10 separate requirements.

REQ-SY-03

System must integrate with PAS when the admin clicks the button and it stores the patient data and also the referral and updates the waiting list but only if the patient is new unless they already exist in which case it updates them.

Multiple requirements conflated into one sentence
Ambiguous conditional logic — "unless they already exist" is unclear
No acceptance criteria separating each scenario
Should be decomposed into at least 3–4 separate requirements

→ Action: Decompose. Separate new patient creation, existing patient update, referral logging, and waiting list update into individual requirements. Clarify conditional logic with the business.

REQ-SY-04

As a system, I want to be GDPR compliant.

Systems do not have wants — actor is structurally invalid
GDPR compliance is a constraint/non-functional requirement, not a system story
No specific behaviour described

→ Action: Move to a constraints register or non-functional requirements section. Work with the IG/data protection team to define specific GDPR-related system behaviours (consent capture, data retention, audit logging, etc.).

Non-Functional Requirements

REQ-NF-01

The system should be fast.

No measurable performance metric
No condition (fast under what load? At what percentile? For which transaction type?)
Entirely untestable as written — cannot form part of an acceptance test

→ Action: Replace with a measurable SLA, e.g. "The system shall return referral search results within 2 seconds for 95% of queries under a concurrent load of 200 users."

REQ-NF-02

Training will be provided to all staff before go-live.

Not a system requirement — this is a project/delivery assumption
Belongs in a project plan, RACI, or implementation strategy — not a requirements document
Gives no information about what the system itself needs to do

→ Action: Remove from requirements document. Transfer to project plan. If a training-related system requirement exists (e.g. e-learning module integration), that is a separate conversation.

How Candidates Should Handle the PM

The PM's instruction to "adopt as-is" is the real test. Strong candidates will:

Acknowledge the PM's position without dismissing it
Frame the risk in business terms — not quality pedantry, but delivery and compliance risk
Propose a structured, time-boxed review process rather than a wholesale rejection
Offer to work collaboratively to improve the requirements rather than simply hand them back
Know when to escalate — if the PM insists, a strong BA raises it with the sponsor

As-Is Process — Answer Guide

Task D — Expected outputs for facilitator reference

Process Owner

The process owner is deliberately ambiguous. There is no single correct answer — which is the point. The Head of Patient Access has nominal ownership but limited operational authority. Each specialty effectively runs its own variant. Strong candidates will:

Flag the ambiguity as itself a finding, not a gap in the case study
Identify this as a root cause — lack of a single accountable owner drives much of the variation
Propose how they would confirm ownership (escalation to COO, RACI facilitation)

Weak candidates will try to name someone without noting the ambiguity.

Expected As-Is Flow

Referral Received — via one of three channels: NHS e-RS, legacy fax, or ad-hoc consultant email. No single intake point.

⚠ Pain point: triplication of channels, no unified queue, no triage function

Manual Sorting — Admin staff in each specialty receive independently. Fax referrals require manual re-keying. No central triage.

⚠ Pain point: duplication of effort, high error risk, no audit trail

PAS Data Entry — Admin enters patient and referral data into legacy PAS. No validation at point of entry. ~22% of records incomplete.

⚠ Pain point: poor data quality, no automated validation

Waiting List Update — Excel spreadsheet updated locally per specialty. No cross-specialty or Trust-wide visibility. Meadowfield not captured.

⚠ Pain point: siloed visibility, MH pathway invisible to reporting

Clinical Review — Consultant or referring clinician reviews. Timing varies by specialty — same day to 10+ days. No SLA enforcement.

⚠ Pain point: no SLA enforcement, no escalation pathway

Appointment Booking — Admin contacts patient by post or phone. No digital self-booking. Cardiology using unapproved third-party tool.

⚠ Pain point: patient experience, shadow IT risk, data governance exposure

Confirmation & Notification — Letter confirmation in most specialties. No automated notifications. Patient cannot self-serve.

⚠ Pain point: patient dissatisfaction, admin burden, no RTT clock visibility

Validation Approaches (Candidates Should Suggest)

Structured interviews with admin staff across specialties
Process observation / job shadowing
Document review: PAS reports, waiting list extracts, fax logs
Swim-lane mapping workshops with process participants
Data analysis: referral volumes, turnaround times, error rates by source
Separate engagement with Meadowfield given distinct system (RiO)

Breakout Task — Answer Guide

Phase 2 — Sandra & Marcus transcript

Expected Pain Points

Unmonitored shared inbox — referrals lost or delayed; no SLA; no acknowledgement. Both sides affected.
Incomplete referral documentation — no checklist communicated to HealthBridge admin teams. Causes downstream chase and delay.
RTT clock risk — referral logged in PAS (clock implied) but not entered in RiO (clock not started). Creates phantom compliance — the Trust looks compliant on paper but isn't operationally. This is the highest-stakes finding.
No formal handoff confirmation — Sandra's team assumes delivery; Marcus's team makes no acknowledgement. Gap sits between the two organisations.
Guidance not circulated cross-organisationally — Meadowfield's 2-year-old checklist never reached HealthBridge admin. Marcus assumed it had been.
Joint care pathway effectively dormant — exists in a 2019 policy document, unknown to acute admin, triggered fewer than a handful of times. Patients with complex needs are not being identified or co-managed.
No holding/pending queue in Meadowfield — incomplete referrals sit informally in an inbox with no tracking, no escalation, no visibility.
No visibility post-handoff — neither side knows what happens after the referral is sent. No feedback loop exists.

Process Gaps & Dependencies

Key Gaps

No defined handoff point between HealthBridge and Meadowfield — the email send is treated as the handoff, but there is no confirmation
PAS and RiO are not integrated — data entered separately, at different times, with no reconciliation
No agreed referral documentation standard shared across both organisations
No joint process for complex patients requiring simultaneous acute and MH management

Dependencies

Any new system design must account for the PAS → RiO data handoff — this is a technical integration requirement
RTT compliance reporting depends on both systems — a unified reporting view requires both to be in sync
The joint care pathway cannot function without a trigger mechanism on the acute side

BA Practice Reflection — Expected Observations

What the BA did well

Got both process owners in the same room — without this, the gap between PAS and RiO entry might never have surfaced
Used open questions consistently and followed threads naturally
Named the RTT finding explicitly and visibly ("that's a significant finding") — good meeting facilitation
Closed with a clear next step (process diagram for validation)

What the BA could have asked

What volume of referrals has a mental health component — is this 5% or 50%?
Has the RTT discrepancy ever been escalated or formally identified before?
Who is responsible for chasing the unmonitored inbox — is there an owner?
What happens when a referral is missed entirely — what is the recovery process?
Can we quantify the impact of the documentation gap — how many referrals are delayed because of missing consent forms?
The 2019 joint pathway — has anyone reviewed it recently? Is it still fit for purpose?

Immediate next steps (strong candidates will suggest)

Produce draft swim-lane process diagram covering both sides and share for validation
Formally document the RTT clock risk as a programme-level risk on the RAID log
Request the Meadowfield referral checklist and the 2019 joint pathway document
Quantify the volume of affected referrals
Arrange a follow-up session to validate the process map and explore the inbox/holding queue issue

Debrief Prompts (Main Room Re-entry)

"What was the single most significant finding in that transcript?"
"What would you put first on a process map from that conversation?"
"If you were that BA, what would you do the moment the meeting ended?"

Interview Questions

Phase 3 — 4–6 questions per candidate, mixed themes

Probe notes are for your use. Do not share them or lead with them — allow the candidate to respond fully first.

Stakeholder Management

Q01 — Stakeholder Relationship Building

From the case study, Dr Priya Soni has escalated her concerns to the ICB and her clinical lead hasn't responded to meeting requests. How would you approach building a relationship with Meadowfield as a BA?

Listen for: Empathy alongside pragmatism. Do they start with understanding Dr Soni's concern, not just the task?

Strong signals: Acknowledges the political dimension. Proposes a structured engagement plan. Considers a different entry point (not the clinical lead who isn't responding).

Weak signals: Purely task-focused ("I'd send another meeting request"). Ignores the ICB escalation as a signal of depth of concern.

Q02 — Stakeholder Conflict

Tell me about a time you had to manage conflicting requirements or priorities between two stakeholders who each had legitimate needs. What did you do and what was the outcome?

Listen for: Structured approach — facilitated session, escalation protocol, documented decision.

Strong signals: Stayed neutral. Brought stakeholders together rather than playing intermediary. Outcome was clear and owned.

Weak signals: Took sides. Resolved it by avoiding the conflict. Outcome is vague or the "win" belongs to the candidate, not the project.

Q03 — Managing Resistance

The Cardiology department has implemented their own unapproved workaround system. As the BA, you need to engage them in the new programme. How do you approach that conversation?

Listen for: Curiosity before compliance. Do they want to understand why Cardiology built the workaround before they address the shadow IT issue?

Strong signals: Frames the workaround as evidence of an unmet need. Uses it to inform requirements. Builds a bridge between Cardiology's solution and the programme intent.

Weak signals: Leads with the governance problem. Treats Cardiology as a risk to manage rather than a stakeholder to engage.

Business Analysis Practice

Q04 — Requirements Challenge

Looking at the requirements you reviewed today — a PM tells you they came from the business and must be adopted as-is. Walk me through how you'd respond to that professionally and what your next steps would be.

Listen for: Professional pushback framed in terms of risk, not standards pedantry.

Strong signals: Acknowledges PM's position. Quantifies the risk of poor requirements (rework, scope creep, failed acceptance testing). Proposes a time-boxed structured review. Knows when to escalate if PM insists.

Weak signals: Accepts the requirements. Pushes back without a constructive alternative. Refers only to "best practice" without connecting it to business impact.

Q05 — Elicitation Techniques

From the breakout transcript — what elicitation techniques did the BA use? What additional techniques would you have deployed in that session, and why?

Listen for: Correct naming of techniques. Reflection on what was missing.

Strong signals: Names structured interview, process walkthrough. Suggests observation, document analysis, or data review as complements. Notes what questions weren't asked.

Weak signals: Can describe what happened but can't name the technique. No critique of the BA's approach.

Q06 — Handling Ambiguity

You're three days into a project and you realise there's no clear process owner — no one agrees who owns referral intake. What do you do?

Listen for: Document, escalate, facilitate — in some form.

Strong signals: Logs as a risk immediately. Proposes a RACI or ownership clarification workshop. Escalates to the sponsor if not resolved quickly. Understands this is a governance issue, not just an admin one.

Weak signals: Tries to decide themselves who the owner is. Waits to see if it resolves itself. Doesn't connect ownership ambiguity to programme risk.

Project Governance

Q07 — Governance Artefacts

How do you approach project governance as a BA? What artefacts do you typically produce or contribute to, and how do you ensure decision-making is properly documented?

Listen for: RAID logs, decision logs, change control, requirements traceability, SteerCo reporting.

Strong signals: Understands governance as accountability infrastructure, not paperwork. Can explain why each artefact matters.

Weak signals: Lists artefacts without connecting them to purpose. Confuses governance with administration.

Q08 — Change Management

Admin teams are reportedly fearful of redundancy. How would you factor change management into your BA approach, and where does your role end and the change manager's begin?

Listen for: Clear view of BA/CM boundary. Empathy alongside process thinking.

Strong signals: Incorporates impact assessments and stakeholder engagement into BA work. Knows when to hand off. Doesn't dismiss admin anxiety as someone else's problem.

Weak signals: "That's the change manager's job." No view of how BA work feeds into the change narrative.

Q09 — Scope Creep

Midway through the programme, the ICB adds a new mandate: the system must also support GP direct access booking. This wasn't in scope. How do you manage this as a BA?

Listen for: Formal change control. Impact assessment. Escalation to sponsor.

Strong signals: Goes through change control. Raises impact on timeline, cost, and resource explicitly. Understands who approves scope changes (not the BA).

Weak signals: Absorbs the change. Treats the ICB mandate as automatically overriding scope. No impact assessment.

Professional Judgement

Q10 — Failure & Learning

Tell me about a project or piece of analysis where things didn't go as planned. What happened and what did you take from it?

Listen for: Genuine accountability without self-flagellation. Real learning applied to later work.

Strong signals: Owns their part clearly. Describes a specific and genuine failure, not a reframed success. Learning is concrete and has been applied.

Weak signals: "The team let me down." Failure is always someone else's fault. Learning is vague ("I communicate better now").

Q11 — Prioritisation Under Constraint

Five stakeholders each consider their requirement the highest priority. You have capacity for three. How do you decide, and how do you communicate to the other two?

Listen for: Framework use (MoSCoW, value/effort, risk-based). Stakeholder involvement in prioritisation. Honest communication.

Strong signals: Uses a transparent framework. Involves stakeholders in the prioritisation conversation rather than deciding alone. Can have the difficult conversation with clarity and empathy.

Weak signals: Decides unilaterally. Avoids the conversation with the "losing" two stakeholders. No framework applied.

Q12 — Self-Awareness

Looking at the HealthBridge case — which aspect would you find most personally challenging, and why?

Listen for: Genuine self-awareness. Intellectual honesty. Does their answer align with their other responses?

Strong signals: Names a specific and credible challenge. Demonstrates they know their own edge. Doesn't perform invulnerability.

Weak signals: "Nothing particularly challenging." The challenge named contradicts strong claims made elsewhere. Generic answer ("stakeholder management is always hard").

Observation Guide

What to watch and note during group phases

Group Phase Observation Prompts

Who takes the lead — and how?

Note whether they invite others in or dominate. Leadership style under time pressure reveals a great deal. A BA who steamrolls in a group setting will likely do the same with stakeholders.

Framework instinct

Do they reach for a structure (RACI, MoSCoW, stakeholder grid, PESTLE) naturally, or do they operate in free-form? Neither is automatically wrong, but note whether the structure is applied confidently or performatively.

Requirements discernment

The key test is REQ-SY-01. Strong candidates will identify it as the best-written requirement and only flag the classification issue. Weaker candidates will criticise everything uniformly or miss it entirely. This is a reliable differentiator.

Process owner ambiguity

Do they flag the ambiguity as a structural problem, or do they just try to name someone? The former demonstrates systems thinking; the latter is surface-level analysis.

Quality of pushback language

When discussing how to respond to the PM on requirements: is their language professional and risk-framed, or do they rely on "best practice says" and standards citation? The best BAs make the business case for good requirements, not the methodology case.

Strong Candidate Signals

Identifies co-stakeholders with competing interests — specifically ICT vs. clinical informatics
Names patients on the stakeholder map without being prompted
Flags the RTT clock risk from the breakout transcript unprompted
Approaches Cardiology with curiosity about why they built the workaround
Distinguishes clearly between symptoms and root causes in Task B
In interview: connects governance to accountability, not just documentation
Shows empathy for admin teams without dismissing the change programme need

Red Flags

Accepts the requirements without any challenge
Names a process owner without acknowledging the deliberate ambiguity
Treats the stakeholder map as a flat list rather than a relational analysis
In interview: reframes every failure as a success ("it was hard but we delivered on time")
Cannot distinguish between BA and PM scope of responsibility
Passive or vague responses to the Meadowfield and Cardiology scenarios
Criticises REQ-SY-01 as heavily as the others — shows inability to discriminate
In breakout: misses the RTT clock finding entirely

Note-Taking Template (per candidate)

Candidate: ___________________
Group contribution (lead / active / passive / disruptive): ___________________
Framework use (yes / partial / no): ___________________
REQ-SY-01 handling: ___________________
Process owner — ambiguity noted? (yes / no): ___________________
Strongest moment: ___________________
Concern: ___________________
Interview Qs used: ___________________
Overall impression: ___________________

Facilitator Guide

Quick Reference

Phase 1 — Main Room Group Work (~65 min)

Phase 2 — Breakout Rooms (~25 min)

Phase 3 — Individual Interviews (~10–15 min each)

Key design note — REQ-SY-01

Timing Guide

Phase 1 — Main Room

Transition

Phase 2 — Breakout

Phase 3 — Interviews

Breakout Room Composition