Eliciting From People Who Won't Say What They Mean
A regional hospital is replacing a scheduling system used by 1,400 clinical staff. The business analyst runs workshops with department heads, who consistently describe the current process as 'fine, just needs to be faster.' When the analyst shadows ward nurses for a day, she observes that nurses maintain a parallel paper roster because the system cannot handle last-minute shift swaps, and that two wards use a shared spreadsheet the IT department does not know exists. The department heads did not mention either workaround. A union representative has asked to be included, citing concerns about how the system records absence. The project deadline is 14 weeks out and the vendor has already begun configuration based on the workshop outputs.
1. Evaluate the elicitation approach used so far and explain why the department head workshops produced misleading information.
Read the worked answer
What the workshops actually produced
The workshops were not worthless, but they captured a managerial view of the process rather than the process itself. Department heads described the system as adequate because, from where they sit, the outputs arrive on time. The failures are absorbed downstream by nurses who compensate silently. That is a classic elicitation gap: the people with authority to approve are not the people with knowledge of the work.
Why the gap appeared
Three mechanisms are at play. First, workarounds are invisible by design. A paper roster and a shadow spreadsheet exist precisely because they are faster than raising a change request, and the people maintaining them have no incentive to advertise them, since doing so can read as admitting non-compliance. Second, the workshop format rewards consensus. In a room with peers and a manager, a nurse who says 'the swap function doesn't work' is contradicting her head of department. Group elicitation suppresses exactly the dissent the analyst needed. Third, the question was wrong. 'How is the current process?' invites a normative answer about how it is supposed to work. Observation answers a different question: what do people actually do when the system fails them?
Assessment of the technique mix
The analyst did the right thing by shadowing, and it should have happened before configuration started, not after. Observation is the correct technique for surfacing tacit workarounds. The gap is sequencing and coverage: no individual interviews with frontline staff, no document analysis of the shadow spreadsheet (which is itself a requirements artifact describing fields the system lacks), and no stakeholder analysis that would have flagged the union.
The union issue
Absence recording is a terms-and-conditions matter. The union is a legitimate stakeholder with veto power in practice, and excluding them until 14 weeks out creates schedule risk far larger than including them now. The analyst should bring them in immediately, before absence-recording requirements are finalized.
Recommendation
Pause configuration on scheduling and absence modules, run individual interviews with nurses on the two anomalous wards, analyse the shadow spreadsheet as a requirements source, and reconvene department heads with the observed evidence so the conversation shifts from opinion to fact.
2. The vendor argues that configuration is already underway and that new requirements from the shadow processes should be deferred to phase two. How should the business analyst frame the decision?
Read the worked answer
The analyst should reframe this from a schedule argument to a risk-and-cost argument, because the vendor's position is defensible on schedule grounds and will win unless the analyst changes the terms of the comparison.
The real question
The question is not 'phase one or phase two.' It is: what happens on go-live day if the system cannot support last-minute shift swaps? The observed evidence answers this. Nurses already maintain a paper workaround. If the new system also cannot swap shifts, the workaround does not disappear; it persists alongside the new system, which means the hospital pays for a replacement system and still runs the manual process. That is the worst of both outcomes and it is the default if the requirement is deferred.
Framing for the decision
The analyst should present three things. First, the specific requirement: shift-swap handling, with the fields the shadow spreadsheet reveals. Second, the consequence of deferral: continued dual running, plus a patient-safety exposure if the paper roster and the system disagree about who is on duty. Third, the cost of inclusion now versus later: adding a swap function during configuration is a configuration and testing effort; adding it after go-live requires data migration of in-flight rosters, retraining, and a second cutover.
The analyst should also be precise about what is genuinely deferrable. Not everything in the shadow spreadsheet belongs in phase one. The analyst should split the discovered requirements into those that prevent the workaround from persisting (must be phase one) and those that merely improve on it (can wait). That gives the vendor a real concession and makes the analyst's position harder to dismiss as scope creep.
Process point
The analyst should also note that the vendor configured against workshop outputs that were known to be incomplete once observation was done. The analyst should not litigate blame, but should establish that requirements discovered through observation before sign-off are not 'new scope'; they are the completion of elicitation that should have preceded configuration.