Replanning a Fixed-Date Release with an Unstable Integration
A utility company is eight weeks from a regulatory deadline for a new customer complaints process built on OutSystems Reactive Web. Scope: 14 screens, two REST integrations (CRM and billing), a BPT approval flow, and a reporting dashboard. The team has seven people: two junior developers, one contractor, two senior developers, one QA and one BA. The CRM sandbox has been unavailable three of the last ten working days. Twenty-two defects are open, eight high severity. Two senior developers were pulled for five days to support a production incident. The sponsor says all scope is mandatory. QA and staging share one environment. The monthly production window is in six weeks. The BA leaves in four weeks. The process must be auditable and available to 400 internal users at launch. Current burn-up shows 60% of stories accepted. The tech lead must re-plan without dropping the regulatory outcome.
1. How do you re-plan scope and release to protect the regulatory date? Show the decision logic.
Read the worked answer
Start from the regulatory outcome, not the 14 screens. Decompose into must-have: complaint intake, triage, approval decision, audit trail, and the CRM integration needed to identify the customer. Defer or phase: reporting dashboard, billing integration if the process can use a manual billing reference at launch, and nonessential UI polish. Present the sponsor with three options: (A) full scope, date at risk; (B) regulatory minimum on date, phase 2 four weeks later; (C) full scope with additional temporary capacity, still risky because the CRM sandbox and BA departure are not solved by money. Recommend B. Build a walking skeleton through the BPT flow and a CRM stub first; replace the stub when the sandbox is stable. Add a two-week hardening sprint before the window, with a defect gate: zero open high-severity defects and 95% of regulatory test cases passed. Freeze scope at week 4. Do not cut audit or security controls. Publish the go/no-go criteria in advance.
2. What governance and communication cadence do you set for the remaining eight weeks?
Read the worked answer
Daily 15-minute stand-up focused on blockers and integration availability. Twice-weekly risk review with tech lead, QA, BA and integration owner; a risk log with owner, trigger and mitigation. Weekly sponsor demo of working software, not status slides; show the regulatory path end to end. A weekly change board for scope: any new request goes to the backlog unless it replaces equal scope. Environment: dedicate staging to this release after week 4; no shared test data changes without notice. Defect triage daily by severity and regulatory impact. Publish a one-page RAG status with burn-up, open high defects, integration uptime, test pass rate and top three risks. Escalate the CRM sandbox to the vendor account manager with a written service-level expectation. Set a go/no-go review five business days before the production window; attendees include sponsor, operations and security.
3. How do you mitigate the BA departure and contractor knowledge risk?
Read the worked answer
Treat knowledge as a deliverable. Before the BA leaves, run two handover workshops: process exceptions and acceptance criteria. Record a decision log and a process map for the BPT flow. Assign a named successor from the business who signs off on the regulatory test cases. For the contractor, require paired development on the two integrations and the approval flow; no sole ownership. Add a code-review rule: every contractor change needs a senior reviewer and a test. Create a short architecture note and runbook. Use the last two weeks before hardening to rotate ownership: the contractor observes while an employee drives. Measure handover by having the successor run a backlog refinement and explain the audit trail to QA. If the BA successor is not available, reduce scope in option B rather than accepting an undocumented process.