Prioritize projects and manage tight deadlines

Q4 Planning Scenario: Prioritization, Scope, and Stakeholder Leadership

You are the sole data lead for Q4 supporting three initiatives with fixed sponsor expectations and limited engineering capacity.

Initiatives

• (A) Courier cancellations: Reduce cancellations by 10% by Nov 15; estimated effort 1.5 eng-weeks; sponsor: VP Operations.
• (B) Merchant quality dashboards: Launch by Oct 30 for the QBR; estimated effort 2 eng-weeks; sponsor: Head of Merchant.
• (C) Pricing uplift experiment: Launch by Nov 30; estimated effort 1 eng-week; sponsor: CPO with +2% revenue expectation.

Constraints

• Capacity: 2 eng-weeks available before Oct 30; 1 eng-week available in November.
• Compliance: Mandatory 1-week lead time before any launch (work must be code-complete one week prior to the date).
• Design: Shared design team cannot work on more than one initiative simultaneously.

Tasks

1. Prioritize and sequence the work using a concrete framework (e.g., RICE or WSJF). State assumptions and the decision rule used.
2. Propose minimal viable scope (MVP) for each initiative that preserves expected impact while fitting constraints. Explain where you cut scope and why.
3. Draft a stakeholder communication plan: what you will commit to each leader, what slips, and how you align on tradeoffs. Include an example status update and a short script for saying no.
4. A critical incident occurs on Oct 25 requiring 0.5 eng-week to fix a data quality issue affecting cancellations. Update your plan: how you renegotiate deadlines and manage risk without eroding trust.
5. Define success criteria for your own performance (leading indicators, risks, contingencies).

Solution

1) Prioritization and Sequencing (Framework, Assumptions, Decision Rule)

Assumptions (explicit):

• "Eng-weeks" are the limiting engineering capacity under my control (analytics/data eng + instrumentation). Design is a separate shared constraint; only (B) needs design; (A) and (C) have minimal/no design dependency.
• Compliance lead time = 1 week means code complete date = launch date − 7 days.
• No additional hires/contractors; if we need more capacity, it requires escalation.

Scheduling guardrail: Latest Start Date (LST)

• LST = Deadline − ComplianceLeadTime − Effort
• If LST is in October, it must fit within the 2 eng-weeks before Oct 30; otherwise it must fit within November's 1 eng-week.

Compute LSTs (before any scope cuts):

• (B) Oct 30 launch → code complete by Oct 23 → effort 2.0 → LST = Oct 9.
• (A) Nov 15 launch → code complete by Nov 8 → effort 1.5 → LST ≈ Oct 25.
• (C) Nov 30 launch → code complete by Nov 23 → effort 1.0 → LST = Nov 16.

Observation: With only 2 Oct eng-weeks total, (B) at 2.0 fully consumes October. November only has 1.0 eng-week, but (A)+(C)=2.5 eng-weeks. Therefore, without scope cuts or renegotiation, the plan is infeasible.

Prioritization framework: WSJF (Weighted Shortest Job First)

• WSJF = Cost of Delay (CoD) / Job Size (effort)
• CoD components (relative 1–10): business value, time criticality, risk reduction/enablement.

Baseline WSJF (pre-scope-cut, relative scoring):

• (B) Dashboards: value 7, time 10 (QBR), enablement 5 → CoD 22; size 2.0 → WSJF 11.
• (A) Cancellations: value 8, time 7, enablement 7 → CoD 22; size 1.5 → WSJF ≈ 14.7.
• (C) Pricing: value 9, time 6, enablement 6 → CoD 21; size 1.0 → WSJF 21.

Decision rule (practical):

• Step 1 (Feasibility gate): Respect hard deadlines/compliance (must hit code-complete by the date or proactively renegotiate).
• Step 2 (WSJF within feasibility): Sequence by highest WSJF, then adjust for design constraints.
• Step 3 (Scope to feasibility): If infeasible, reduce scope to minimally preserve expected impact; if still infeasible, drive a trade-off decision with sponsors.

Applying the rule:

• (B) has a hard QBR deadline with compliance; must secure an October slot.
• To accommodate (A) and (C), we must cut scope. The least-risk pattern: trim (B) to a QBR-ready MVP (no advanced drill downs), reduce (A) to the top root-cause fix + monitoring, and simplify (C) to a server-side multiplier test.

High-level sequence (pre-incident):

• Oct window (2.0 weeks): (B) MVP 1.5 weeks (Oct 9–23 code complete) → compliance Oct 23–30; remaining 0.5 week split before/after for either (C) or (A) pre-work.
• Nov window (1.0 week): Split across (A) and (C) to reach code-complete before their compliance windows.

2) Minimal Viable Scope (MVP) and Scope Cuts

(A) Courier cancellations (target −10% by Nov 15):

• MVP scope (reduce to 1.0 eng-week):
  • Instrumentation and monitoring: daily cancellation-rate monitor by city/vertical; alerts for spikes.
  • Root-cause taxonomy enrichment (e.g., structured reason codes from courier app and ops tools).
  • Top-1 or Top-2 cause fix or playbook (e.g., merchant item unavailable/long prep time; courier reassignment threshold tweak; ETA accuracy improvement via feature flag).
• Cuts/defer:
  • Full ML ETA revamp; multi-cause surgical fixes; automated feedback loops. Rationale: one high-leverage fix + monitoring can deliver most of the early impact.

(B) Merchant quality dashboards (QBR by Oct 30):

• MVP scope (reduce to 1.5 eng-weeks + focused design):
  • Single landing page with 5 core KPIs (fulfillment rate, on-time readiness, cancellations, average prep time, defect rate) with daily refresh.
  • Filters: date range, region, merchant segment; download/CSV export.
  • Role-based access to QBR audience; productionized pipeline with data quality checks.
• Cuts/defer:
  • Historical deep-dive pages, cohorting, alerting, time-series anomaly detection, merchant drill-downs. Rationale: QBR needs consistent single source of truth, not full self-serve v1.

(C) Pricing uplift experiment (Nov 30):

• MVP scope (keep at 1.0 eng-week total):
  • Server-side price multiplier (e.g., +x% on delivery fee or service fee) for a narrow region/category using the existing experimentation platform.
  • Predefined guardrails: conversion, take-rate, cancellations, customer support contacts.
  • Telemetry: exposure logs, assignment, key outcomes; no new UI/design.
• Cuts/defer:
  • Multi-arm bandits, dynamic price elasticity model, broad rollout, complex stratification. Rationale: prove +2% feasibility on a small slice first.

3) Stakeholder Communication Plan

Commitments (pre-incident):

• VP Ops (A): Commit to MVP focused on top cancellation driver + monitoring; code complete by Nov 5; compliance Nov 8–15; launch Nov 15. Risk: if top cause is not dominant, impact may be <10%; we will have a contingency next-best fix pre-scoped.
• Head of Merchant (B): Commit to QBR-ready dashboard MVP code-complete by Oct 23; compliance Oct 23–30; launch Oct 30. Clear list of post-QBR enhancements.
• CPO (C): Commit to a narrow-scope server-side price test: code complete by Nov 20; compliance Nov 23–30; launch by Nov 30. Guardrails and success review in early Dec.

Trade-offs (made explicit):

• To hit (B) QBR, (B) must be MVP. The freed 0.5 Oct week funds pre-work for (A) or (C). November’s 1.0 week must be split between (A) and (C), so both must be MVP and tightly scheduled.

Illustrative schedule (pre-incident):

• Oct 1–4: (C) MVP pre-work (0.5 wk)
• Oct 9–23: (B) MVP build (1.5 wks) → Compliance Oct 23–30
• Oct 23–30: (A) MVP pre-work (0.5 wk) in parallel with (B) compliance
• Nov 1–5: (A) finish (0.5 wk) → Compliance Nov 8–15 → Launch Nov 15
• Nov 16–20: (C) finish (0.5 wk) → Compliance Nov 23–30 → Launch Nov 30

Sample weekly status update (concise):

• Status (as of Oct 18):
  • (B) Dashboards: GREEN. 65% complete; data model finalized; front-end MVP in progress. On track for code complete Oct 23; compliance scheduled Oct 23–30.
  • (A) Cancellations: YELLOW. Root-cause taxonomy validated; pre-work slated for Oct 23–30. Risk: data quality variance in courier reason codes; mitigation: add normalization step.
  • (C) Pricing: GREEN. Experiment design locked; exposure logging stubbed; 0.5 wk remaining in Nov.
• Risks/asks: None this week; design fully allocated to (B) until Oct 23.

Script for saying no (principled trade-off):

• "Given a fixed 2 eng-weeks before Oct 30 and 1 eng-week in November, plus a mandatory 1-week compliance lead time, we can deliver the QBR dashboard and the cancellations MVP by their dates. To also deliver the pricing test by Nov 30, we would need +0.5 eng-week or to further reduce the dashboard scope. If additional capacity isn’t available, I recommend we keep the dashboard MVP for QBR and proceed with the pricing test as scoped, with a contingency to slip a few days if the cancellations work runs long. Which trade-off do you prefer?"

4) Critical Incident on Oct 25 (0.5 eng-week): Plan Update and Renegotiation

Impact: The Oct 25 data quality incident consumes the 0.5 eng-week planned for (A) pre-work during Oct 23–30. (B) remains GREEN (already code-complete on Oct 23). This creates a November capacity crunch.

Updated capacity and schedule:

• Oct: consumed by (B) 1.5 wks + incident 0.5 wk. No (A) pre-work in Oct.
• Nov (only 1.0 wk total):
  • (A) now needs full 1.0 wk in Nov 1–7 to hit code-complete by Nov 7 → Compliance Nov 8–15 → Launch Nov 15.
  • (C) has 0.5 wk completed in early Oct but still needs 0.5 wk to reach code-complete by Nov 22. There’s no November capacity left. Therefore (C) slips unless we add capacity or reduce (A) further.

Renegotiation plan (early, transparent, options-based):

• With CPO (C):
  • Present options: (1) Slip launch to Dec 7 (code-complete Nov 30 → Compliance Dec 1–7), or (2) reduce (C) to a micro-canary limited to one DMA with a shorter observation period and accept lower confidence, still requiring 0.5 eng-week in early Dec; or (3) add 0.5 eng-week from another team between Nov 16–20.
  • Recommendation: Slip to Dec 7 with pre-computed guardrails/holdouts ready, so we protect (A) and keep (B) delivered for QBR. Commit to deliver pre-analysis and experiment configuration dry-run in parallel (non-eng tasks) so time-to-value is minimized.
• With VP Ops (A):
  • Confirm we’re still GREEN by pulling the full 1.0 wk Nov 1–7. Offer to include a second tactical mitigation (playbook) if the incident root cause overlaps with cancellation drivers.
• With Head of Merchant (B):
  • Confirm successful Oct 30 launch. Share backlog for post-QBR enhancements and the date we can resume work based on (A)/(C) outcomes.

Trust-preserving actions:

• Communicate within 24 hours of incident: impact, new plan, and clear rationale using capacity math and compliance gates.
• Publish a one-pager with the revised timeline, risks, and explicit asks (e.g., +0.5 eng-week by Nov 16 if the CPO wants Nov 30 retained).
• Keep a decision log noting who agreed to which trade-offs and when.

5) Success Criteria (for My Performance)

Leading indicators:

• Milestone adherence: code-complete dates vs. plan; compliance submissions at least 1 business day before cutoff.
• Risk burn-down: open risks count trending down weekly; all risks have owners and mitigations.
• Stakeholder alignment: weekly status consumed (open/read), decisions recorded within 48 hours, no unplanned surprises.
• Quality gates: unit/integration tests passing; data validation checks (freshness, completeness, invariants) ≥ 99% for (B); experiment telemetry completeness ≥ 98% for (C).

Outcome indicators:

• (B) dashboard usage by QBR audience (≥ 80% of intended viewers log in; data trusted, zero critical defects).
• (A) measurable reduction in cancellations: at least −7% within 2 weeks as an interim target; plan to reach −10% with second mitigation if needed.
• (C) experiment runs with guardrails respected; statistically valid read on primary metric within 2 weeks post-launch.

Key risks and contingencies:

• Compliance delays: submit early; have a pre-checked artifact list; reserve a 0.25 wk buffer before compliance.
• Design contention: constrain (B) to a single layout; reuse components; avoid design for (A)/(C).
• Data quality incidents: predefine triage SLAs; maintain rollback plans and feature flags; have a frozen change window 48 hours before compliance submission.
• Capacity shocks: pre-agree a cut list (e.g., defer (C) to Dec) and an escalation playbook to request +0.5 eng-week if an incident hits during compliance windows.

Summary of the updated plan after the incident:

• (B) Launch Oct 30 (on track; compliance Oct 23–30).
• (A) Code-complete Nov 7; compliance Nov 8–15; launch Nov 15.
• (C) Slip to Dec 7 unless +0.5 eng-week is added mid-November; pre-work complete and ready to resume immediately after (A).

This plan is feasible, preserves the most time-critical commitments, and manages trust by making trade-offs explicit, quantified, and jointly decided.