Fixed-Date Vaccine Scheduler with Moving Eligibility Rules
A state health agency must launch a public vaccine-scheduling portal by October 1 under a statutory deadline, seven months away. The portal must serve 1.2 million residents, integrate with three legacy systems (immunization registry, eligibility rules, identity verification), and meet WCAG 2.1 AA. Eligibility tiers are set by a committee that has changed them five times in three months. The vendor contract is fixed-price with a fixed scope signed last year. The agency's last large IT project failed after an 18-month waterfall effort delivered a system that did not match clinic workflows. The new team has eight people, including one business analyst and one tester. The agency has a strong privacy office but no continuous integration pipeline; the vendor's team is offshore and communicates through a weekly status call.
1. Recommend a life-cycle approach and explain how it can honor both the fixed date and the changing eligibility rules.
Read the worked answer
Use a hybrid approach: a fixed-date release train with iterative, two-week development cycles inside it. The date is fixed, but scope must be prioritized rather than frozen.
- Define a minimum launch scope: registration, identity verification, eligibility check, appointment search, and confirmation. Defer administrative dashboards and reporting if necessary.
- Put eligibility rules in a configurable rules engine or external configuration so committee changes do not require code releases. Test each rule change with automated cases.
- Run sprint reviews with clinic staff and the privacy office, not just status meetings, so workflow problems surface early.
- Maintain stage gates for security, privacy, accessibility, and load testing before launch.
- Use rolling-wave planning and a visible risk register; the offshore vendor needs written decisions and demonstration-based acceptance, not weekly verbal updates.
The fixed-price contract is a poor fit for high uncertainty. Separate rule-configuration work from core build, document changes, and negotiate a capped change pool rather than pretending the original scope is still accurate.
2. Describe the verification and validation activities and release gates you would require before October 1.
Read the worked answer
Verification asks whether the system was built correctly; validation asks whether it meets user and legal needs.
Verification: unit and integration tests for every interface, automated regression on eligibility rules, static analysis, dependency scanning, and traceability from requirements to test cases. Load-test at three times expected peak, including the identity provider.
Validation: usability testing with older adults and people who use screen readers or magnification; WCAG 2.1 AA audit by an independent accessibility specialist; user acceptance testing with county clinics; data reconciliation with the immunization registry; and a privacy impact assessment.
Release gates: no open critical or high security defects; accessibility blockers closed with documented alternatives; successful restore and failover test; signed data-sharing agreements; and a go/no-go decision by the business owner, privacy officer, and security lead. Add a soft-launch period with limited users. Because the team has one tester, contract for independent penetration and accessibility testing rather than assuming the single tester can cover both.
3. How should the agency handle the fixed-price contract when eligibility rules keep changing?
Read the worked answer
First distinguish clarification from change. A new eligibility tier that alters business rules is a change, not a defect. Log each request with date, source, impact on schedule, cost, and test effort. Ask the vendor for a written impact assessment before authorizing work.
Then choose among four responses: absorb it within the prioritized backlog by dropping lower-value scope; issue a change order with a capped budget; move rule changes to a separate configuration contract; or defer the change to a post-launch release if the statute permits.
Do not direct the vendor to absorb unlimited changes under a fixed-price contract; that invites disputes, hidden quality problems, or a claim later. Equally, do not let the vendor use change control to block legally required changes. Escalate through a governance board with the agency's program, legal, and procurement offices. Keep a decision log and update the schedule baseline. If changes exceed a threshold, renegotiate the contract structure rather than pretending the fixed scope still exists.