Case Study: Outsourced Build Outcome
Mẫu & ví dụ Product OKR Case StudiesOutsourced product dùng shared OKR charter để nối vendor delivery với client business outcome.
Mẫu, ví dụ đã điền và cách dùng
Case Study: Outsourced Build Outcome
Case này giúp client/vendor tránh tình trạng vendor ship đúng sprint nhưng business outcome không đổi.
Business context và pain
| Business context | Insurance company thuê vendor build claims intake MVP để giảm manual triage. |
| User/stakeholder pain | Vendor demo đều, velocity tốt, nhưng operations vẫn phải sửa nhiều claim submissions và client quyết scope chậm. |
| Evidence observed | Only 45% claims pass first validation; UAT reject rate 22%; average decision turnaround 6 business days. |
| Assumptions | Nếu intake validation và client decision SLA cải thiện, manual triage sẽ giảm. |
| Open questions | Validation rules nào reduce most triage? Client decision nào đang block vendor? Acceptance criteria nào chưa rõ? |
OKR structure và decisions
| Objective | Launch claims intake MVP that reduces manual triage for operations. |
| KR 1 | 80% submitted claims pass first validation. |
| KR 2 | Client decision turnaround under 2 business days. |
| KR 3 | Accepted story rate in UAT above 90%. |
| Final artifact | Client-Vendor OKR Charter + Dependency/RACI Log + Outcome Acceptance Packet. |
Success metrics và cách track
| Metric | Cách đo |
|---|---|
| First validation pass | Claims passing automated validation / submitted claims. |
| Decision turnaround | Median business days from decision request to logged decision. |
| Accepted story rate | UAT accepted stories / completed stories. |
Cách triển khai trong 30-60-90 ngày
- First 30 days: define shared OKR charter, decision SLA and UAT examples.
- Days 31-60: ship validation rules and track acceptance evidence.
- Days 61-90: review triage reduction and update contract governance.
Pitfalls và lesson learned
- Lesson: outsourced delivery still needs outcome governance.
- No-no: measuring vendor only by story points or milestone date.
- Advanced move: separate vendor-owned quality metrics from client-owned business decisions.
Điều đã xảy ra: vendor giao đủ, kết quả không đổi
| Cam kết trong hợp đồng | Vendor giao | Kết quả kinh doanh |
|---|---|---|
| 18 tính năng trong 9 tháng | 18/18, đúng hạn | Thời gian xử lý hồ sơ: không đổi |
| Chất lượng: lỗi nghiêm trọng ≤3/tháng | Đạt | — |
| Tài liệu bàn giao | Đủ | — |
Không ai vi phạm gì. Vendor làm đúng hợp đồng, client trả đủ tiền, và dự án được coi là hoàn thành. Chỉ có điều lý do ban đầu để làm dự án — rút thời gian xử lý hồ sơ từ 11 phút xuống 4 phút — không đạt được chút nào.
Nguyên nhân gốc: hợp đồng đặc tả đầu ra, không đặc tả kết quả. Khi 18 tính năng được chốt từ tháng đầu, không có cơ chế nào để phát hiện rằng tính năng số 7 không có tác dụng và lẽ ra nên đổi.
Ba điểm rẽ đã bị bỏ lỡ
| Thời điểm | Tín hiệu có sẵn | Điều lẽ ra nên làm | Thực tế đã làm |
|---|---|---|---|
| Tháng 3 | 5 tính năng đầu đã chạy, thời gian xử lý không đổi | Dừng lại, đo xem thời gian thật đi đâu | Tiếp tục theo danh sách |
| Tháng 5 | Nhân viên vẫn in hồ sơ ra giấy để đối chiếu | Hỏi vì sao — đây là đường vòng, là bằng chứng | Ghi nhận là "thói quen cũ" |
| Tháng 7 | Vendor đề xuất một thay đổi ngoài phạm vi | Xem xét nghiêm túc | Từ chối vì "không có trong hợp đồng" |
Điểm rẽ tháng 5 là điểm đắt nhất. Việc nhân viên vẫn in hồ sơ ra giấy là dấu hiệu rõ ràng rằng hệ thống mới chưa thay được quy trình cũ — nhưng nó được diễn giải thành vấn đề thói quen con người thay vì vấn đề sản phẩm.
Điều tìm ra sau này: phần lớn 11 phút không nằm ở việc nhập liệu — nó nằm ở việc chờ phê duyệt của một người ở phòng khác. Không tính năng nào trong 18 tính năng chạm vào bước đó.
Lẽ ra nên làm khác thế nào
- Viết charter trước khi viết danh sách tính năng. Outcome của client và cơ chế nhân quả phải có trước — xem kỹ năng Client-Vendor OKR Charter.
- Đo hiện trạng chi tiết trước khi bắt đầu. 11 phút gồm những bước nào, mỗi bước bao lâu. Việc này mất hai ngày và đã có thể thay đổi cả dự án.
- Đặt điểm kiểm kết quả ở tháng 3, không chỉ ở cuối. Với điều kiện rõ ràng: nếu thời gian xử lý chưa giảm ít nhất 15%, dừng lại và xem lại giả định.
- Cho vendor một phần thưởng gắn với kết quả, dù nhỏ — nó đổi hẳn động lực đề xuất thay đổi khi họ thấy việc đang làm không có tác dụng.
- Coi đường vòng của người dùng là dữ liệu chính thức, không phải chuyện thói quen.
Áp dụng vào tình huống của bạn
Bốn câu hỏi kiểm tra một hợp đồng thuê ngoài trước khi ký — mỗi câu ứng với một điểm mà ca này đã hỏng.
| Câu hỏi | Trả lời "không" nghĩa là | Sửa thế nào |
|---|---|---|
| Hợp đồng có nêu outcome kinh doanh kèm con số không? | Bạn đang mua đầu ra và hy vọng kết quả tự đến | Viết charter trước khi viết phạm vi |
| Đã đo hiện trạng chi tiết chưa? | Không có cách nào chứng minh cải thiện, và không biết thời gian thật đi đâu | Đo trước, mất 1–2 ngày |
| Có điểm kiểm kết quả giữa chừng với điều kiện dừng không? | Sai hướng sẽ chỉ lộ ra ở cuối, khi đã tiêu hết tiền | Đặt mốc ở 1/3 thời gian, có ngưỡng cụ thể |
| Vendor có động lực nào gắn với kết quả không? | Họ được thưởng vì giao đủ, nên họ sẽ giao đủ | Một phần nhỏ thù lao gắn với outcome |
Về việc đo hiện trạng: đây là bước rẻ nhất và bị bỏ nhiều nhất. Trong ca này, hai ngày đo sẽ phát hiện rằng phần lớn 11 phút nằm ở bước chờ phê duyệt — và toàn bộ dự án 9 tháng đã có thể được thiết kế khác.
Và một dấu hiệu cần chú ý trong suốt dự án: khi vendor đề xuất thay đổi ngoài phạm vi, đừng phản xạ từ chối. Họ đang ở gần mã nguồn và gần người dùng hơn bạn — đề xuất đó thường là tín hiệu sớm nhất bạn có.
Definition of done
- Hợp đồng nêu outcome kinh doanh kèm con số, không chỉ nêu danh sách tính năng.
- Hiện trạng đã được đo chi tiết theo từng bước trước khi bắt đầu.
- Có điểm kiểm kết quả ở khoảng 1/3 thời gian, kèm điều kiện dừng.
- Đường vòng của người dùng được coi là dữ liệu chính thức, không phải thói quen.
- Đề xuất ngoài phạm vi từ vendor được xem xét, không bị từ chối theo phản xạ.
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| Client Product Owner | Đặc tả đầu ra mà không đặc tả kết quả là cách thất bại đúng hợp đồng |
| Vendor PM | Bị từ chối đề xuất vì "ngoài phạm vi" là tín hiệu hợp đồng đang sai cấu trúc |
| Business Analyst | Đo hiện trạng chi tiết trước khi bắt đầu là việc rẻ nhất và bị bỏ nhiều nhất |
| Business Sponsor | Điểm kiểm kết quả giữa chừng là thứ duy nhất cứu được dự án đi sai hướng |
| Delivery Manager | Bạn là người nhìn thấy đường vòng của người dùng sớm nhất — đừng ghi nhận nó là thói quen cũ |
| Mua sắm / pháp chế | Hợp đồng chỉ ràng buộc đầu ra sẽ được thực hiện đúng và vẫn thất bại |
Thảo luận & tài liệu thêm 0
Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.