Business Context

Figma is midway through a 12-week engineering project to rebuild its multiplayer comments service. The project is high priority because comments are used by 62% of weekly active teams, and the current service causes latency spikes during peak collaboration hours. Leadership wants a simple, defensible way to determine whether the project is on track before the next executive review.

Metric Scenario

The team committed to shipping by June 30 with four major milestones: design sign-off, backend migration, client integration, and production rollout. As of week 6, the project dashboard shows: 52 of 100 planned story points completed, 2 of 4 milestones done, 3 open P1 risks (target: <=1), 18 open bugs in the test environment (target: <=10), build success rate 91% (target: >=95%), and forecasted completion date July 11 based on the current burn rate. Engineering leadership is asking whether the project is truly on track or whether the apparent 52% completion masks schedule risk.

Requirements

1. Define a primary metric or scorecard for whether the project is on track.
2. Distinguish between leading indicators and lagging indicators for project health.
3. Show how you would combine schedule, scope, quality, and risk into a clear KPI framework.
4. Explain how you would interpret the current numbers and whether you would escalate.
5. Propose guardrails so the team does not hit the date by sacrificing quality or reliability.

Data Available

• project_plan: milestone_name, planned_date, actual_date, owner, status
• sprint_board: sprint_id, story_id, story_points, status, created_at, completed_at
• bug_tracker: bug_id, severity, environment, status, created_at, resolved_at
• ci_cd_runs: run_id, branch, test_pass_rate, build_status, deploy_time
• risk_log: risk_id, severity, mitigation_owner, opened_at, closed_at