The Portal That Grew Two Heads
A public sector body is replacing a customer portal. The original scope was a like-for-like replacement of an enquiry form. Over five months, scope has grown to include online payments, document upload, appointment booking and a case-tracking dashboard. There are 210 requirements in the register, of which 60 are marked 'must'. The sponsor has not attended the last three steering meetings. Two departments have submitted overlapping requirements for notifications with different wording and timing. The delivery team says the fixed date in eleven months is unachievable at current scope. No non-functional requirements have been written.
1. How do you approach prioritisation and scope control here?
Read the worked answer
Start by establishing that 60 'musts' is not a priority list - it is a symptom of uncontrolled scope. Then:
- Re-anchor on objectives. Confirm with the sponsor what outcomes the portal must deliver and by when, so priority has a basis beyond departmental preference.
- Facilitate a prioritisation workshop using a recognised method (for example MoSCoW with explicit effort and risk, or weighted scoring against objectives). Require each 'must' to be justified by a consequence of exclusion. Typically a large proportion are reclassified.
- Resolve duplication between the two departments' notification requirements by eliciting the underlying need and agreeing a single consolidated requirement with one owner.
- Make trade-offs visible - present the sponsor with options: reduce scope, extend the date, or increase capacity. Do not silently absorb the gap.
- Use incremental delivery so the highest-value scope lands first and lower-priority items can follow.
- Record decisions and update the requirements register with status and rationale.
Scope control is a sponsor decision; your job is to make the decision unavoidable and well-informed.
2. Two departments have submitted overlapping notification requirements with different wording and timing. How do you resolve this?
Read the worked answer
Treat the two submissions as expressions of need rather than competing specifications.
- Elicit the underlying need from each department: why the notification, to whom, and what action it should prompt. Different wording often reflects different audiences or purposes that can be served by one configurable solution.
- Identify commonality and genuine difference. Separate what is truly required from what is habit or preference.
- Model the notification - trigger, recipient, content, channel, timing - and test both submissions against the model.
- Propose a consolidated requirement with parameters for wording and timing where difference is legitimate, and a single default where it is not.
- Get both departments to agree the consolidated requirement in a joint session, and record the agreement and any residual divergence.
Avoid writing two overlapping requirements into the register; that guarantees later conflict and rework. If agreement fails, escalate to the sponsor with the impact of the unresolved conflict.
3. No non-functional requirements exist. What do you do, and why does it matter here?
Read the worked answer
Non-functional requirements are often decisive for a public-facing portal and are expensive to retrofit. Their absence is a material gap, not a documentation nicety.
Actions:
- Elicit them systematically using categories: performance (response times under load), capacity (concurrent users, document sizes), availability, security and access control, accessibility (public sector bodies typically have legal accessibility obligations), data protection and retention, auditability, usability and browser/device support.
- Make them measurable. 'Fast' is not a requirement; a stated response time under a defined load is.
- Involve the right people - technical architects, security, legal and representatives of users with accessibility needs.
- Prioritise and record them alongside functional requirements, and trace them to acceptance criteria and test approach.
- Raise the risk to the sponsor: without these, the delivery team cannot size the solution credibly, and the eleven-month estimate is unreliable.
For a portal handling payments and personal documents, security, availability and accessibility are likely to be among the highest-priority requirements.