Describe tight and missed deadlines

Below is a teaching-oriented approach and two model answers you can adapt. Use STAR (Situation, Task, Action, Result), quantify impact, and explicitly show ownership, prioritization, and risk management. --- Guiding framework - Plan: Break down work, estimate, identify critical path, create a risk register. Use a quick capacity plan (team availability × sprint days). - Prioritize: Use MoSCoW (Must/Should/Could/Won't) or impact vs. risk. Protect the critical path; delay non-essentials. - Negotiate scope: Offer concrete trade-offs tied to outcomes (e.g., "ship API contract now, defer admin UI"). - Communicate risks: Set a cadence (daily async update + checkpoints), define RAG (Red/Amber/Green) status, and keep a decision log. - After-action: Capture metrics and lessons learned; adjust process. Simple estimation math - Capacity (dev-days) = number_of_engineers × focus_factor × days. - Example: 3 engineers × 0.7 focus × 10 workdays ≈ 21 dev-days. - If Must-have tasks sum to 18 dev-days, you have only ~3 dev-days left for Should/Could. --- Part A — Tight deadline (model answer) Situation: A payment partner deprecated their v1 API with a hard cutoff in 3 weeks. If we missed it, transactions would fail for ~35% of orders, risking revenue and customer trust. Task: Deliver a v2 integration (auth changes, new webhooks, idempotency), migrate traffic safely, and avoid checkout downtime. Action: 1) Planning and estimation - Decomposed into 12 stories: core client, retries/backoff, idempotency keys, webhook signatures, feature flag, canary, dashboards, runbooks, migration script. - Estimated at 22 dev-days; team capacity was ~21 dev-days (3 engineers × 0.7 focus × 10 days). Identified critical path: client + auth + idempotency + canary. - Created a risk register: partner rate limits, signature mismatch, webhook retries, PCI review queue. 2) Prioritization and scope negotiation - Must: client, idempotency, canary, rollback, minimal dashboards. - Should: admin UI and full alerting coverage. - Could: auto-replay tool and full backfill of legacy metadata. - Negotiated with PM: defer admin UI and full alerting to post-cutover; agreed on a 2-hour change freeze window during peak. 3) Execution and communication - Daily 10-minute async updates with RAG status; twice-weekly 15-minute stakeholder checkpoint. - Implemented feature flags and a 5% → 25% → 50% → 100% canary ramp with error budgets (abort if p95 latency > 300 ms or error rate > 0.5%). - Paired on signature verification; wrote contract tests against partner’s sandbox; set up Grafana dashboards and a runbook with rollback steps. Result: - Shipped 2 days before cutoff; ramped to 100% with 0 critical incidents. - Checkout success rate improved from 97.8% to 99.2% for the migrated traffic; p95 payment call latency dropped 18%. - Avoided estimated revenue risk (35% of orders). Completed deferred admin UI and alerts in the following sprint. - Retrospective outputs: keep risk register + feature flags + canary playbook for all external integrations. Why this works: It demonstrates ownership, customer focus, trade-off clarity, and risk-driven execution with measurable outcomes. --- Part B — Missed deadline (model answer) Situation: We committed to migrate application logs to a new observability platform in 4 weeks to cut costs and improve search latency. Task: Deliver ingestion, schemas, and a 90-day backfill with parity dashboards before the end of the billing cycle. Action: 1) What went wrong (root causes) - Underestimated backfill complexity: schema drift across 14 services required transforms; the vendor enforced rate limits we hadn’t validated. - Hidden dependency: needed infra team approval for cross-account IAM roles; approval took 5 business days. - Scope creep: added partitioning and dedup improvements mid-sprint without adjusting timeline. 2) How I handled stakeholders - Flagged risk at day 10 (Amber) with a clear slip range (+5 to +8 days) based on a prototype ingest test. - Presented options: (a) phase 30-day backfill now, finish remaining 60 days next sprint; (b) keep 90-day goal but slip by 1 week; (c) maintain old pipeline in read-only mode for safety. - We chose option (a). Communicated daily progress, published a decision log, and set SLOs for parity (95% ingest within 5 minutes; dashboard parity on top 10 queries). 3) Outcome - Missed original deadline by 1 week for full 90-day backfill, but shipped 30 days on time and maintained monitoring parity with no alert coverage gaps. - Cost reduction achieved (–22%) a week late; search p95 improved by 35% after full completion. 4) What I changed to prevent recurrence - Estimation: added a time-boxed spike (1–2 days) for any new vendor/data migration to validate rate limits, schema, and throughput. - Buffers: applied a 20–30% contingency for projects with external dependencies. - Dependencies: introduced a lightweight dependency map with owners and lead times; no start without confirmed SLAs/approvals. - Scope control: formalized a change control checklist; any mid-sprint scope adds require explicit trade-offs and timeline updates. - Risk tracking: weekly risk burndown review; use RAG with pre-defined exit criteria. Lessons to emphasize - Own the miss: provide data, options, and a path to value even if phased. - Make risks explicit early, with ranges and triggers. - Turn the retrospective into durable mechanisms (spikes, buffers, dependency SLAs, change control, risk burndown). --- How to adapt quickly for your own stories - Pick projects with clear stakes (customer impact, revenue, availability). - Quantify: success rate, latency, error rate, revenue protected, cost saved. - Name 2–3 key trade-offs you proposed and the rationale. - Show proactive comms: cadence, RAG, decision log, demos. - End with mechanisms you institutionalized so the benefit outlives the project.