Với một người, điều đó có nghĩa là năm trang và bố cục gọn gàng hơn. Với người khác, điều đó có nghĩa là việc di chuyển blog, các trang đích mới, nội dung được cập nhật và logo mà họ đã muốn thiết kế lại từ nhiều tháng nay.
Phạm vi công việc sẽ giải quyết vấn đề đó. Nó xác định những gì dự án sẽ cung cấp, cách thức hoàn thành công việc, thời hạn hoàn thành từng phần, những gì được coi là đã được phê duyệt và những gì nằm ngoài phạm vi thỏa thuận.
Sự rõ ràng quan trọng hơn bạn tưởng. Báo cáo CHAOS của Standish Group cho thấy chỉ khoảng 31% dự án hoàn thành đúng hạn và trong phạm vi công việc đã định.
Đây là phần khó chịu: phần lớn những sai sót đó không phải do vấn đề kỷ luật. Đó là vấn đề về quản lý tài liệu. Tài liệu phạm vi công việc được ký kết, gửi qua email và lưu trữ, và từ thời điểm đó, nó bắt đầu lệch khỏi công việc thực tế. Đến tuần thứ ba, tài liệu ghi là năm trang trong khi dự án lại là mười lăm trang, và không ai có thể chỉ ra chính xác khoảng cách đó bắt đầu từ đâu. Giải pháp không phải là một tài liệu SOW dài hơn. Đó là một phạm vi công việc luôn có kết nối chặt chẽ với công việc mà nó mô tả.
Hướng dẫn này sẽ chỉ cho bạn cách soạn thảo phạm vi công việc sao cho đủ rõ ràng để định giá, lập kế hoạch, phân công, phê duyệt và quản lý sau khi dự án chính thức khởi động.
Tóm tắt
Một phạm vi công việc hiệu quả phải trả lời được bốn câu hỏi: bạn sẽ cung cấp gì, thực hiện như thế nào, hoàn thành vào thời điểm nào và tiêu chí nào được coi là đã xong. Phạm vi công việc hiệu quả nhất không phải là bản chi tiết nhất, mà là bản vẫn giữ được tính trung thực và minh bạch sau 30 ngày.
Các chi tiết có thể bị lãng quên khi công việc bắt đầu, do đó việc duy trì một tài liệu cập nhật xuyên suốt dự án là điều cần thiết. Điều này đảm bảo rằng các nội dung “nằm ngoài phạm vi công việc” được định nghĩa rõ ràng và có thể tham chiếu được.
Bao quát đầy đủ bảy thành phần, và thay vì sử dụng các động từ mơ hồ như “quản lý”, hãy chỉ định số cụ thể như “4 bài đăng/tháng”. Nêu rõ những việc bạn không thực hiện, chỉ ra các yếu tố phụ thuộc từ phía khách hàng gây ra phần lớn sự chậm trễ, và luôn yêu cầu sự chấp thuận bằng văn bản cho mọi yêu cầu thay đổi trước khi bắt đầu công việc. Sau đó, kết nối tài liệu đã ký với các công việc đang thực hiện, để khi phạm vi công việc mở rộng, sự thay đổi sẽ được hiển thị rõ ràng và có thể định giá, thay vì diễn ra âm thầm và miễn phí.
Phạm vi công việc là gì?
Phạm vi công việc (SOW) là tài liệu xác định chính xác những gì dự án sẽ cung cấp, cách thức thực hiện, thời hạn hoàn thành và những gì được coi là công việc hoàn thành. Tài liệu này xác định rõ ràng phạm vi công việc để tất cả các bên — khách hàng, nhà cung cấp và các nhóm nội bộ — thống nhất về các sản phẩm đầu ra trước khi bắt đầu.
Nhiệm vụ của SOW là đảm bảo sự thống nhất. Tài liệu SOW xác định các mục tiêu, liệt kê các sản phẩm đầu ra, chia nhỏ chúng thành các công việc, liên kết chúng với dòng thời gian và nêu rõ cách đánh giá việc hoàn thành từng sản phẩm đầu ra. Nó trở thành tài liệu tham chiếu mà mọi người đều dựa vào khi có thắc mắc hoặc thay đổi phát sinh. Đó cũng chính là lý do tại sao SOW đóng vai trò là xương sống của việc quản lý dự án.
Sự khác biệt giữa Phạm vi công việc và Tuyên bố công việc là gì?
Phạm vi công việc (Scope of Work) xác định những việc cần làm; còn Thỏa thuận công việc (Statement of Work) mô tả cách hai bên sẽ hợp tác để thực hiện những việc cần làm đó. Cả hai đều chia sẻ viết tắt là SOW và thường được sử dụng thay thế cho nhau, nhưng chúng hoạt động ở các cấp độ khác nhau.
Một thuật ngữ tương tự khác là “phạm vi dự án”. Thuật ngữ này xác định ranh giới của chính dự án, những gì được bao gồm và những gì không, thay vì tập trung vào công việc hoặc mối quan hệ làm việc.
| Tài liệu | Nội dung hướng dẫn này giải đáp những vấn đề gì | Thông thường bao gồm | Khi bạn sử dụng nó |
|---|---|---|---|
| Phạm vi công việc | Công việc cần làm là gì | Mục tiêu, sản phẩm đầu ra, công việc, dòng thời gian, tiêu chí chấp nhận, các nội dung không bao gồm | Xác định một nhiệm vụ cụ thể hoặc giai đoạn dự án |
| Bản mô tả công việc | Cách các bên sẽ hợp tác với nhau trong công việc | Phạm vi công việc cùng các điều khoản pháp lý, lịch thanh toán, bảo hành và cơ chế quản lý | Thỏa thuận hợp đồng đầy đủ, thường bao gồm SOW được đính kèm bên trong |
| Phạm vi dự án | Phạm vi đầy đủ của dự án | Tất cả các sản phẩm đầu ra và công việc cần thiết để hoàn thành chúng, cùng với những nội dung nằm ngoài phạm vi công việc | Lập kế hoạch nội bộ và quản lý phạm vi công việc trong toàn bộ dự án |
Trên thực tế, “Tuyên bố công việc” (Statement of Work) là hợp đồng tổng thể, còn “Phạm vi công việc” là phần bên trong hợp đồng đó nêu rõ các sản phẩm đầu ra. Phạm vi dự án là khái niệm kế hoạch mà cả hai tài liệu này đều mô tả. Nếu một bên liên quan yêu cầu “SOW”, bạn nên dành 10 giây để xác minh xem họ đang đề cập đến tài liệu nào, bởi vì các điều khoản pháp lý và thanh toán được quy định trong “Tuyên bố công việc”, chứ không phải trong “Phạm vi công việc”.
Phạm vi công việc bao gồm những gì? Các thành phần cốt lõi
Một SOW hoàn thành phải giúp công việc dễ hiểu, dễ định giá, dễ lập kế hoạch và dễ được phê duyệt. Nếu thiếu một thành phần cốt lõi nào đó, bạn sẽ tạo ra cơ hội cho sự nhầm lẫn sau này.
Dưới đây là những nội dung cần bao gồm:
- Mục tiêu và mục đích: Phần này giải thích lý do tại sao công việc này tồn tại và kết quả mà nó cần đạt được. Hãy giữ phần này trong vòng một hoặc hai câu, được viết bằng ngôn ngữ của khách hàng. Ví dụ, “Nâng cao khả năng thu hút khách hàng tiềm năng tự nhiên từ blog công ty” sẽ rõ ràng hơn so với “thực hiện chiến lược nội dung”.
- Kết quả đầu ra: Đây là những sản phẩm cụ thể mà bạn sẽ bàn giao. Hãy nêu tên và định lượng chúng bất cứ khi nào có thể. Hãy viết “12 bài đăng trên mạng xã hội mỗi tháng trên LinkedIn và Instagram”, chứ không phải “quản lý mạng xã hội”
- Công việc và hoạt động: Phần này phân tích chi tiết công việc cần thực hiện để hoàn thành từng sản phẩm đầu ra. Phần này không cần liệt kê từng hành động nhỏ nhất, nhưng phải đủ chi tiết để người đọc hiểu rõ công việc bao gồm những gì. Đối với dự án thiết kế lại trang web, phần này có thể bao gồm thiết kế wireframe, viết nội dung, phát triển, kiểm thử chất lượng (QA) và hỗ trợ ra mắt.
- Dòng thời gian và các cột mốc quan trọng: Sử dụng phần này để trình bày cách dự án sẽ diễn ra từ khi khởi động đến khi hoàn thành. Bao gồm ngày bắt đầu, ngày kết thúc, các giai đoạn chính, các điểm đánh giá và các yếu tố phụ thuộc. Một dòng thời gian dự án vững chắc giúp mọi người nắm rõ những việc cần thực hiện trước khi giai đoạn tiếp theo có thể bắt đầu
- Tiêu chí chấp nhận: Phần này xác định cách thức từng sản phẩm đầu ra sẽ được đánh giá, phê duyệt và coi là hoàn thành. Khách hàng sẽ biết rõ tiêu chuẩn chất lượng cần đạt được, còn bạn sẽ biết khi nào có thể đóng công việc thay vì phải sửa đổi vô thời hạn.
- Các nội dung không bao gồm và các giả định: Tại phần này, hãy nêu rõ những gì không được bao gồm và các điều kiện mà dự án phụ thuộc vào. Ví dụ, bạn có thể loại trừ việc quản lý quảng cáo trả phí khỏi SOW về nội dung hoặc giả định rằng khách hàng sẽ cung cấp hướng dẫn về thương hiệu trước khi bắt đầu công việc. Phần này giúp ngăn chặn tình trạng mở rộng phạm vi công việc ngay từ đầu
- Chi phí và điều khoản thanh toán: Phần này đề cập đến tổng chi phí, cơ cấu thanh toán, lịch thanh toán và các điều kiện kích hoạt thanh toán. Nhiều tài liệu SOW gắn việc thanh toán với các cột mốc quan trọng, chẳng hạn như ký kết hợp đồng, bàn giao bản nháp đầu tiên, phê duyệt cuối cùng hoặc hoàn thành dự án
- Vai trò và trách nhiệm: Xác định rõ ai là người chịu trách nhiệm cho từng sản phẩm đầu ra, ai là người phê duyệt và ai là người liên hệ duy nhất của khách hàng
Có những loại phạm vi công việc nào?
Phạm vi công việc thường được chia thành bốn cấu trúc. Cấu trúc phù hợp nhất phụ thuộc vào mức độ dự đoán được của dự án, mức độ rõ ràng khi xác định các sản phẩm đầu ra, và mức độ rủi ro mà mỗi bên sẵn sàng chấp nhận.
- Dựa trên sản phẩm đầu ra (thiết kế/xây dựng): Loại này gắn việc thanh toán và phê duyệt với các sản phẩm đầu ra cụ thể. Phương thức này phát huy hiệu quả nhất khi các sản phẩm đầu ra đã được xác định rõ ràng, chẳng hạn như một trang web có số trang cố định, một số lượng nhất định các tài sản thiết kế hoặc một loạt bài viết blog đã được xác định trước.
- Thời gian và vật tư: Cấu trúc này tính phí dựa trên số giờ làm việc, công cụ và chi phí phát sinh trong quá trình thực hiện công việc. Cấu trúc này phù hợp với các dự án mà phạm vi công việc vẫn chưa rõ ràng, đòi hỏi nhiều giai đoạn nghiên cứu ban đầu hoặc có khả năng thay đổi. Hãy sử dụng cấu trúc này khi danh sách công việc cố định chỉ mang tính phỏng đoán hơn là một kế hoạch cụ thể.
- Mức độ nỗ lực: Loại hình này cam kết một lượng thời gian, hỗ trợ hoặc nguồn lực cố định trong một khoảng thời gian xác định. Loại hình này thường được áp dụng cho các hợp đồng cố định, tư vấn liên tục, bảo trì và công việc hỗ trợ, trong đó các công việc cụ thể có thể thay đổi theo từng tuần, nhưng mức độ dịch vụ vẫn được duy trì ổn định.
- Dựa trên hiệu quả: Cấu trúc này gắn việc thanh toán với kết quả hoặc các chỉ số đo lường được, thay vì số giờ công việc hoặc tài sản được bàn giao. Phương thức này chỉ hiệu quả khi cả hai bên thống nhất về một chỉ số đo lường rõ ràng, cơ sở tham chiếu được xác định rõ ràng và nhà cung cấp có đủ quyền kiểm soát đối với kết quả.
Lựa chọn nhanh:
- Các sản phẩm đầu ra cố định, được xác định rõ ràng → dựa trên sản phẩm đầu ra
- Phạm vi công việc không chắc chắn hoặc đòi hỏi nhiều công tác khảo sát → thời gian và vật liệu
- Hỗ trợ liên tục hoặc hợp đồng cố định → mức độ nỗ lực
- Thanh toán gắn liền với kết quả rõ ràng, có thể đo lường được → dựa trên hiệu suất
Hầu hết các tranh chấp về phạm vi công việc đều bắt nguồn từ việc cấu trúc tài liệu không phù hợp với công việc thực tế. Một SOW dựa trên các sản phẩm đầu ra có thể phù hợp với dự án xây dựng website theo giá cố định, nhưng sẽ tiềm ẩn rủi ro đối với các dự án vẫn cần nghiên cứu, chiến lược hoặc sự thống nhất giữa các bên liên quan. Nếu bạn chưa thể xác định cụ thể các sản phẩm đầu ra, đừng cố gắng giả vờ rằng bạn đã có thể làm điều đó trong SOW. Hãy sử dụng một cấu trúc phản ánh sự không chắc chắn đó.
Cách soạn thảo phạm vi công việc (Quy trình từng bước)
Để soạn thảo SOW, hãy xác định mục tiêu, liệt kê các sản phẩm đầu ra và các yếu tố không thuộc phạm vi công việc, chia nhỏ chúng thành các công việc, thiết lập dòng thời gian kèm theo các mối quan hệ phụ thuộc, viết tiêu chí chấp nhận, nêu rõ các giả định và quy trình kiểm soát thay đổi, sau đó bổ sung chi phí và ký duyệt. Bảy bước này sẽ dẫn dắt dự án từ giai đoạn khởi động đến khi kết thúc. Trong thực tế:
Bước 1: Xác định mục tiêu và tiêu chí thành công
Hãy bắt đầu bằng việc xác định lý do tại sao công việc này được thực hiện và kết quả mong đợi sẽ như thế nào. Đây chính là nền tảng cho toàn bộ tài liệu SOW. Nếu mục tiêu không rõ ràng, các sản phẩm đầu ra, dòng thời gian và quy trình phê duyệt cũng sẽ trở nên mơ hồ.
Viết mục tiêu trong một hoặc hai câu mà khách hàng có thể dễ dàng nhận ra. Tránh sử dụng thuật ngữ nội bộ và các cụm từ chung chung như “nâng cao sự hiện diện của thương hiệu” hoặc “hỗ trợ các nỗ lực tiếp thị”. Thay vào đó, hãy liên kết công việc với một kết quả kinh doanh rõ ràng.
Ví dụ:
- Mục tiêu chưa rõ ràng: “Tạo ra một trang web tốt hơn.”
- Mục tiêu cụ thể hơn: “Thiết kế lại trang web để giúp người mua B2B hiểu sản phẩm nhanh hơn và gửi yêu cầu demo với tỷ lệ bỏ dở thấp hơn.”
Sau đó, hãy bổ sung các tiêu chí đánh giá thành công. Điều này không nhất thiết phải là một chỉ số KPI cụ thể, đặc biệt nếu dự án mang tính sáng tạo hoặc tập trung nhiều vào giai đoạn khám phá. Tuy nhiên, nó cần giải thích cách cả hai bên sẽ xác định được công việc đã hoàn thành đúng mục tiêu.
Bước 2: Danh sách công việc: Các sản phẩm đầu ra và các nội dung không thuộc phạm vi công việc
Tiếp theo, hãy liệt kê từng sản phẩm đầu ra mà khách hàng sẽ nhận được. Hãy cụ thể, có thể đếm được và thẳng thắn.
Tránh sử dụng các động từ chung chung như “quản lý”, “hỗ trợ”, “xử lý” hoặc “tối ưu hóa” trừ khi bạn định nghĩa rõ chúng bao gồm những gì. Những từ này nghe có vẻ hữu ích trong bản đề xuất, nhưng chúng tạo ra kẽ hở cho việc mở rộng phạm vi công việc trong tài liệu SOW.
Ví dụ:
- Kết quả đầu ra không rõ ràng: “Quản lý blog của công ty.”
- Kết quả đầu ra cụ thể hơn: “Đăng bốn bài viết blog tối ưu hóa công cụ tìm kiếm (SEO) mỗi tháng, mỗi bài từ 1.500 đến 2.000 từ, bao gồm một vòng chỉnh sửa cho mỗi bài.”
Phiên bản chi tiết hơn sẽ cho khách hàng biết họ sẽ nhận được gì, mức độ cụ thể ra sao và ranh giới công việc nằm ở đâu. Sau đó, lập danh sách các hạng mục không nằm trong phạm vi công việc trong cùng phần đó. Đây chính là nơi bạn cần nêu rõ những gì không được bao gồm trong công việc, ngay cả khi điều đó có vẻ hiển nhiên đối với bạn.
Đối với một dự án blog, các hạng mục không thuộc phạm vi công việc có thể bao gồm:
- Nghiên cứu từ khóa ngoài phạm vi kế hoạch nội dung đã được phê duyệt
- Tải bài viết lên hệ thống quản lý nội dung (CMS)
- Hình ảnh hoặc minh họa tùy chỉnh
- Phỏng vấn các chuyên gia trong lĩnh vực (SME)
- Mỗi bài viết có thể trải qua nhiều hơn một vòng chỉnh sửa
- Quảng bá trên mạng xã hội sau khi xuất bản
Ví dụ thực tế: Hệ thống xử lý hành lý tại Sân bay Quốc tế Denver
Hệ thống xử lý hành lý tự động hóa tại Sân bay Quốc tế Denver là một bài học cảnh báo hữu ích cho bất kỳ tài liệu SOW nào.
Mục tiêu chính nghe có vẻ đơn giản: xây dựng hệ thống xử lý hành lý tự động hóa cho sân bay mới. Tuy nhiên, công việc thực tế lại liên quan đến nhiều nhà ga, hãng hàng không, loại hành lý, quy tắc định tuyến và các trường hợp ngoại lệ trong vận hành.
Theo báo cáo đánh giá của GAO về dự án này, năm 1992, thành phố Denver đã trao cho BAE Automated Systems một hợp đồng trị giá khoảng 195,6 triệu USD. Đến năm 1995, chi phí đã tăng lên hơn 290 triệu USD. Lễ khai trương sân bay cũng bị hoãn từ tháng 10 năm 1993 sang tháng 2 năm 1995 do các vấn đề về hệ thống và những thay đổi lớn.
Phạm vi công việc liên tục thay đổi do việc bổ sung các băng chuyền, xử lý hành lý có kích thước bất thường, thiết bị bảo trì, cập nhật lộ trình và các thay đổi theo yêu cầu của hãng hàng không. Một thỏa thuận sau đó đã giảm sức chứa xử lý hành lý từ 65 kiện mỗi phút trên mỗi dây chuyền xuống còn 30 kiện. Denver cũng phải xây dựng một hệ thống xử lý hành lý sao lưu truyền thống, mà GAO ước tính trị giá 63 triệu USD.
Bài học: Đừng chỉ xác định sản phẩm đầu ra chính; hãy xác định cả các giới hạn xung quanh nó. “Hệ thống xử lý hành lý tự động hóa” lẽ ra phải nêu rõ các hãng hàng không, loại hành lý, các trường hợp ngoại lệ, quy trình dự phòng và các tiêu chuẩn kiểm thử nào được bao gồm hoặc loại trừ.
Tuy nhiên, việc xác định ranh giới trên giấy tờ không phải là giải pháp toàn diện. Denver đã có một phạm vi công việc. Điều mà họ thiếu chính là kết nối giữa phạm vi đó với quá trình triển khai thực tế, do đó mọi yêu cầu về băng tải, thay đổi lộ trình và yêu cầu từ hãng hàng không đều trở thành các thỏa thuận phụ mà tài liệu ban đầu không bao giờ tích hợp được. Tài liệu và dự án triển khai đã trở thành hai dự án riêng biệt.
Bước 3: Chia các sản phẩm đầu ra thành các công việc
Sau khi lập danh sách công việc đầu ra, hãy thực hiện một bài kiểm tra đơn giản: liệu ai đó có thể bắt đầu công việc ngay từ dòng này vào ngày mai không?
Nếu câu trả lời là "không", thì phạm vi đó vẫn còn quá rộng.
Hãy xử lý từng sản phẩm đầu ra một và chia nhỏ thành các công việc ở cấp độ nhiệm vụ theo định dạng động từ + đối tượng. Ví dụ: “tạo bản phác thảo trang chủ”, “kiểm tra nội dung pháp lý”, “phê duyệt thiết kế cuối cùng” hoặc “tải bài viết blog lên hệ thống quản lý nội dung (CMS)”. Tránh sử dụng các tên công việc mơ hồ như “công việc liên quan đến website”, “hỗ trợ nội dung” hoặc “cập nhật thiết kế”. Những tên này không thể hiện rõ ai sẽ thực hiện công việc gì.
Đối với một dự án viết blog (4 bài viết blog tối ưu hóa SEO mỗi tháng), việc phân chia công việc có thể như sau:
| Công việc | Chủ đầu tư | Phụ thuộc |
|---|---|---|
| Xác nhận các chủ đề và từ khóa | Chuyên gia chiến lược nội dung/Chuyên gia chiến lược SEO | Khách hàng phê duyệt kế hoạch nội dung |
| Tạo bản tóm tắt | Chuyên gia chiến lược nội dung | Từ khóa đã được xác nhận |
| Viết bản nháp đầu tiên | Người viết | Các bản tóm tắt đã được phê duyệt |
| Kiểm tra tính chính xác của sản phẩm | Chuyên gia về khách hàng (SME) | Bản nháp đã nộp |
| Chỉnh sửa để đảm bảo cấu trúc và tính rõ ràng | Trình chỉnh sửa | Đã bổ sung ý kiến của các chuyên gia |
| Thêm liên kết nội bộ và siêu dữ liệu | Chuyên gia SEO | Đã hoàn thành các chỉnh sửa cuối cùng |
| Tải lên hệ thống quản lý nội dung (CMS) | Quản lý nội dung | Khách hàng phê duyệt bản thảo cuối cùng |
Tầng công việc này phơi bày khối lượng công việc thực tế đằng sau sản phẩm đầu ra. Nó cũng chỉ ra những điểm có thể xảy ra chậm trễ. Nếu chuyên gia nội dung (SME) của khách hàng không xem xét bản nháp đúng hạn, trình chỉnh sửa, chuyên gia SEO và quản lý nội dung đều sẽ bị chậm tiến độ. Sự phụ thuộc này cần được làm rõ trước khi dự án bắt đầu.
Đối với các dự án quy mô lớn, hãy sử dụng cấu trúc phân chia công việc (WBS). Điều này có nghĩa là phân nhóm công việc theo từng giai đoạn, sau đó chia nhỏ từng giai đoạn thành các công việc cụ thể được phân công. Ví dụ, việc thiết kế lại trang web có thể bao gồm các giai đoạn: nghiên cứu, sơ đồ trang web, bản phác thảo giao diện, nội dung, thiết kế, phát triển, kiểm thử chất lượng (QA), thiết lập phân tích dữ liệu và ra mắt. Mỗi giai đoạn sau đó cần được cụ thể hóa thành các công việc riêng lẻ, kèm theo người chịu trách nhiệm, ngày đáo hạn và điểm phê duyệt.
Bạn có thể xây dựng bản đồ công việc này trong:
- ClickUp, Asana hoặc monday.com để quản lý chủ sở hữu, thời hạn, mối quan hệ phụ thuộc và theo dõi trạng thái
- Jira cho phạm vi công việc về phần mềm, sản phẩm và kỹ thuật
- Sử dụng Trello để triển khai theo phong cách Kanban một cách đơn giản hơn
- Sử dụng Miro hoặc FigJam để tạo bản đồ quy trình làm việc một cách trực quan trước khi chia nhỏ thành các công việc cụ thể
- Google Trang tính hoặc Excel nếu khách hàng muốn có một bảng công việc đơn giản làm tệp đính kèm với SOW
Bước 4: Cài đặt dòng thời gian, các cột mốc quan trọng và các mối phụ thuộc
Bây giờ, hãy chuyển danh sách công việc thành dòng thời gian. Thêm ngày bắt đầu, ngày kết thúc, các cột mốc quan trọng và bất kỳ yếu tố phụ thuộc nào có thể ảnh hưởng đến việc hoàn thành công việc.
Đừng chỉ ghi “Dự án phải hoàn thành trong sáu tuần.” Hãy chia dòng thời gian thành các giai đoạn, chẳng hạn như giai đoạn tìm hiểu, bản nháp đầu tiên, xem xét, chỉnh sửa, phê duyệt cuối cùng và triển khai. Sau đó, đánh dấu các cột mốc quan trọng nào sẽ kích hoạt việc thanh toán, phê duyệt hoặc chuyển sang giai đoạn tiếp theo của công việc.
Ví dụ:
- Cuộc họp khởi động phải hoàn thành trước ngày 3 tháng 5
- Nhà cung cấp cung cấp các tài sản thương hiệu trước ngày 6 tháng 5
- Bản nháp đầu tiên sẽ được gửi trước ngày 15 tháng 5
- Phản hồi của khách hàng phải được gửi trong vòng ba ngày làm việc
- Bản sửa đổi cuối cùng sẽ được gửi trước ngày 24 tháng 5
- Hạn chót phê duyệt cuối cùng là ngày 28 tháng 5
Phần quan trọng nhất là xác định các yếu tố phụ thuộc, đặc biệt là những yếu tố từ phía khách hàng. Nhiều sự chậm trễ trong dự án không xuất phát từ công việc thực tế. Chúng thường do phản hồi chậm trễ, thiếu quyền truy cập đăng nhập, việc rà soát pháp lý bị trì hoãn, các bên liên quan không thể liên lạc được, hoặc các tài nguyên được cung cấp sau khi nhóm đã bắt đầu triển khai.
Hãy làm rõ những điều này trước khi bắt đầu công việc.
Ví dụ: “Dòng thời gian dự án phụ thuộc vào phản hồi kịp thời từ khách hàng, khả năng tiếp cận các công cụ cần thiết và việc cung cấp các tài sản thương hiệu đã được phê duyệt. Sự chậm trễ trong phản hồi, phê duyệt, quyền truy cập hoặc tài liệu có thể làm thay đổi dòng thời gian dự án tương ứng với số ngày làm việc tương ứng.”
Bước 5: Lập tiêu chí chấp nhận cho từng sản phẩm đầu ra
Đối với mỗi sản phẩm đầu ra, hãy xác định rõ tiêu chí để được coi là đã được phê duyệt. Đây chính là điều khoản giúp ngăn chặn dự án rơi vào vòng luẩn quẩn của những lần chỉnh sửa “gần như hoàn tất” kéo dài vô tận.
Hãy đảm bảo các tiêu chí phải liên quan đến các kiểm tra có thể quan sát được. Đối với việc di chuyển trang web, “sẵn sàng ra mắt” có thể có nghĩa là các liên kết chuyển hướng đã được kiểm tra, các công cụ phân tích đang hoạt động, các biểu mẫu liên hệ hoạt động bình thường và các trang đã được phê duyệt tải đúng trên cả máy tính để bàn và thiết bị di động. Đối với bản trình bày bán hàng, điều này có thể mang ý nghĩa hoàn toàn khác.
Tránh sử dụng ngôn ngữ phê duyệt chỉ dựa trên cảm tính, chẳng hạn như “khách hàng hài lòng với công việc”. Một cách diễn đạt tốt hơn sẽ là:
“Sản phẩm hoàn thành được chấp nhận khi đáp ứng các tiêu chí đã thỏa thuận, bao gồm cả vòng sửa đổi đã được phê duyệt và nhận được sự chấp thuận bằng văn bản từ khách hàng.”
Điều này giúp cả hai bên có một điểm kết thúc rõ ràng. Các yêu cầu mới sau đó vẫn có thể phát sinh, nhưng chúng sẽ được xử lý dưới dạng yêu cầu thay đổi thay vì mở rộng phạm vi công việc ban đầu.
Bước 6: Nêu rõ các giả định, các trường hợp loại trừ và quy trình kiểm soát thay đổi
Đây chính là nơi giúp bạn ngăn chặn việc mở rộng phạm vi dự án một cách âm thầm.
Giả định
- Phản hồi từ khách hàng sẽ được cung cấp trong vòng ba ngày làm việc
- Tất cả các tệp nguồn cần thiết sẽ được cung cấp trước khi bắt đầu dự án
- Một người ra quyết định duy nhất sẽ phê duyệt cuối cùng
Các trường hợp loại trừ
- Thiết kế logo
- Bảo trì định kỳ
- Yêu cầu trang mới nằm ngoài phạm vi đã thỏa thuận
- Hỗ trợ SEO sau khi ra mắt
Quy trình kiểm soát thay đổi
- Bất kỳ công việc nào nằm ngoài phạm vi này đều phải được yêu cầu bằng văn bản
- Yêu cầu này sẽ được xem xét về tác động đến chi phí và dòng thời gian
- Cả hai bên phải đồng ý với sự thay đổi trước khi bắt đầu công việc
Phần cuối cùng này là quan trọng nhất. Nếu nhà cung cấp hoàn thành công việc bổ sung trước rồi mới thảo luận về thanh toán sau, việc thực thi yêu cầu thay đổi sẽ trở nên khó khăn hơn rất nhiều.
Ví dụ thực tế: Dự án Hồ sơ vụ án ảo (Virtual Case File) của FBI
Dự án Hồ sơ vụ án ảo (Virtual Case File) của FBI là một ví dụ điển hình cho thấy tại sao việc kiểm soát thay đổi và các cột mốc quan trọng cần được đưa vào phạm vi công việc ngay từ đầu.
Dự án này nhằm hiện đại hóa hệ thống quản lý hồ sơ vụ án của FBI. Tuy nhiên, theo báo cáo đánh giá của Thanh tra Tổng cục Tư pháp (DOJ), FBI và các nhà thầu của họ đã thiếu sự hiểu biết rõ ràng về các yêu cầu thiết kế khi công việc tiến độ. Một quản lý dự án của FBI cho biết phạm vi của chương trình Trilogy đã tăng khoảng 80% sau khi dự án bắt đầu.
Cấu trúc hợp đồng cũng khiến vấn đề trở nên khó kiểm soát hơn. Cuộc rà soát cho thấy các bản mô tả công việc không bao gồm các cột mốc hoàn thành cụ thể và các điểm đánh giá quyết định quan trọng, đồng thời cũng không quy định các hình thức xử phạt nếu các cột mốc này không được hoàn thành đúng hạn.
Dự án cuối cùng đã bị hủy bỏ sau khi đã chi khoảng 170 triệu đô la.
Bài học: Hãy xác định quy trình xử lý thay đổi trước khi bắt đầu công việc. Tài liệu SOW cần nêu rõ cách thức đề xuất, định giá, phê duyệt các thay đổi cũng như cách tích hợp chúng vào dòng thời gian dự án, kèm theo các cột mốc và điểm đánh giá cụ thể. Nếu không, các thay đổi về phạm vi công việc sẽ trở thành những quyết định không chính thức, và những quyết định không chính thức sẽ gây tốn kém.
Đó là sai lầm tương tự như trường hợp PDF đã được lưu trữ, chỉ khác là ở quy mô $170M: các bản mô tả công việc vẫn giữ nguyên trong khi yêu cầu thay đổi liên tục. Do không có gì kết nối phạm vi công việc với công việc thực tế, nên không có cơ chế nào để theo kịp mức tăng trưởng 80% khi nó diễn ra.
Bước 7: Thêm chi phí, điều khoản thanh toán và chữ ký xác nhận
Kết thúc tài liệu SOW bằng các điều khoản thương mại: tổng giá trị hợp đồng, cơ cấu thanh toán, lịch thanh toán, ngày đáo hạn thanh toán, điều khoản xử lý chậm thanh toán và người được ủy quyền phê duyệt công việc.
Hãy liên kết các khoản thanh toán với các cột mốc hoàn thành rõ ràng khi có thể. Ví dụ:
- 40% phải thanh toán khi ký hợp đồng
- 30% phải thanh toán sau khi hoàn thành sản phẩm chính đầu tiên hoặc gửi bài nộp/gửi bản nháp
- 30% thanh toán sau khi bàn giao hoặc phê duyệt cuối cùng
Đối với các dự án dài hạn, hãy nêu rõ mức phí cố định hàng tháng, ngày thanh toán, phạm vi công việc được bao gồm, cũng như các biện pháp xử lý khi khách hàng vượt quá số giờ hoặc sản phẩm đầu ra đã thỏa thuận.
Sau đó, hãy yêu cầu xác nhận bằng văn bản. Một SOW chưa được phê duyệt chỉ là bản nháp làm việc. Chữ ký xác nhận rằng cả hai bên đã thống nhất về các sản phẩm đầu ra, dòng thời gian, các điều khoản loại trừ, điều kiện thanh toán và quy trình thay đổi trước khi bắt đầu công việc.
Tạo tài liệu Phạm vi công việc (SoW) chỉ trong vài phút với mẫu sẵn sàng sử dụng này
Mẫu Phạm vi công việc (SOW) của ClickUp cung cấp cho bạn một tài liệu sẵn sàng sử dụng để ghi lại các chi tiết dự án, sản phẩm đầu ra, trách nhiệm, dòng thời gian, quản lý thay đổi, ngân sách và các bước phê duyệt tại một nơi duy nhất. Mẫu này rất hữu ích khi bạn muốn đưa SOW trở thành một phần của quy trình làm việc dự án.
Tại sao nên sử dụng mẫu này:
- Lập bản đồ các phần cốt lõi của SOW ngay từ đầu, bao gồm bối cảnh và mục tiêu, sản phẩm đầu ra, trách nhiệm của nhà cung cấp, trách nhiệm của khách hàng, dòng thời gian, kế hoạch giao tiếp, quản lý thay đổi, ngân sách và các thủ tục phê duyệt
- Liên kết SOW với địa điểm tương ứng trên ClickUp để tài liệu này được kết nối trực tiếp với dự án thực tế
- Sử dụng hơn 15 chế độ xem tùy chỉnh như Xem dạng danh sách công việc, Biểu đồ Gantt, Khối lượng công việc và Lịch để biến phạm vi công việc đã được lập thành công việc có thể theo dõi, bao gồm người chịu trách nhiệm, thời hạn và các mối quan hệ phụ thuộc
- Thêm các Trường Tùy chỉnh và trạng thái để theo dõi tiến độ phê duyệt, các thay đổi về phạm vi công việc, chi tiết ngân sách và trách nhiệm của các bên liên quan trong suốt quá trình triển khai dự án
Ví dụ về phạm vi công việc theo ngành
Một tài liệu SOW thường bao gồm các phần cốt lõi giống nhau trong mọi ngành: mục tiêu, sản phẩm đầu ra, dòng thời gian, giả định, các nội dung không bao gồm, tiêu chí chấp nhận, điều khoản thanh toán và thủ tục ký kết.
Điều thay đổi chính là rủi ro.
Các dự án website thường gặp thất bại do các vấn đề liên quan đến số lượng trang, các lần sửa đổi, quyền sở hữu hệ thống quản lý nội dung (CMS) và hỗ trợ sau khi ra mắt. Trong khi đó, phạm vi công việc trong xây dựng thường gặp vấn đề do các yếu tố như giấy phép, điều kiện công trường, việc kiểm tra và những thay đổi về vật liệu.
Hãy sử dụng các ví dụ dưới đây như những hướng dẫn để xây dựng phạm vi công việc của riêng bạn, chứ không phải là các hợp đồng để sao chép nguyên văn.
Dưới đây là một mẫu SOW về thiết kế lại trang web ở dạng tóm tắt, với mọi phần cốt lõi đã được điền đầy đủ:
Mục tiêu: Thay thế trang web tiếp thị để giúp người mua B2B hiểu sản phẩm nhanh hơn và tăng số lượng đăng ký dùng thử.
Kết quả đầu ra: 8 trang được thiết kế và phát triển dựa trên sơ đồ trang web đã được phê duyệt, 2 vòng chỉnh sửa cho mỗi trang, bàn giao hệ thống quản lý nội dung (CMS) và một phiên đào tạo kéo dài 1 giờ.
Dòng thời gian: 6 tuần chia thành 3 cột mốc quan trọng: phê duyệt thiết kế (tuần 2), hoàn thành xây dựng (tuần 4), ra mắt (tuần 6).
Tiêu chí chấp nhận: Mỗi trang phải được phê duyệt dựa trên bản thiết kế đã ký, hiển thị chính xác trên cả máy tính để bàn và thiết bị di động, và nhận được sự chấp thuận bằng văn bản từ khách hàng.
Các nội dung không bao gồm: Viết nội dung, cấp phép sử dụng ảnh stock, các trang mới ngoài sơ đồ trang web, di chuyển SEO, bảo trì sau khi ra mắt.
Thanh toán: 40% khi ký hợp đồng, 30% khi hoàn thành xây dựng, 30% khi ra mắt.
Kiểm soát thay đổi: Mọi yêu cầu nằm ngoài phạm vi này đều được ghi nhận, đánh giá tác động về chi phí và dòng thời gian, và phải được phê duyệt bằng văn bản trước khi bắt đầu công việc.
Mục tiêu: Thay thế trang web tiếp thị để giúp người mua B2B hiểu sản phẩm nhanh hơn và tăng số lượng đăng ký dùng thử.
Kết quả đầu ra: 8 trang được thiết kế và phát triển dựa trên sơ đồ trang web đã được phê duyệt, 2 vòng chỉnh sửa cho mỗi trang, bàn giao hệ thống quản lý nội dung (CMS) và một phiên đào tạo kéo dài 1 giờ.
Dòng thời gian: 6 tuần chia thành 3 cột mốc quan trọng: phê duyệt thiết kế (tuần 2), hoàn thành xây dựng (tuần 4), ra mắt (tuần 6).
Tiêu chí chấp nhận: Mỗi trang phải được phê duyệt dựa trên bản thiết kế đã ký, hiển thị chính xác trên cả máy tính để bàn và thiết bị di động, đồng thời nhận được sự chấp thuận bằng văn bản từ khách hàng.
Các nội dung không bao gồm: Viết nội dung, cấp phép sử dụng ảnh stock, các trang mới ngoài sơ đồ trang web, di chuyển SEO, bảo trì sau khi ra mắt.
Thanh toán: 40% khi ký hợp đồng, 30% khi hoàn thành xây dựng, 30% khi ra mắt.
Kiểm soát thay đổi: Mọi yêu cầu nằm ngoài phạm vi này đều được ghi nhận, đánh giá tác động về chi phí và dòng thời gian, và phải được phê duyệt bằng văn bản trước khi bắt đầu công việc.
Phạm vi công việc (SOW) cho công ty sáng tạo hoặc dự án thiết kế lại trang web
Rủi ro trong công việc phát triển website nằm ở những công việc ẩn. Khách hàng có thể cho rằng các công việc như viết nội dung, tối ưu hóa SEO, tạo trang mới, hình ảnh stock, đồ họa tùy chỉnh, tải lên hệ thống quản lý nội dung (CMS) và hỗ trợ sau khi ra mắt đều đã được bao gồm, trừ khi tài liệu SOW có quy định khác.
Bao gồm:
- Số trang hoặc mẫu tài liệu
- Trách nhiệm về thiết kế và phát triển
- Số vòng chỉnh sửa trên mỗi trang
- Chuyển giao hoặc đào tạo về hệ thống quản lý nội dung (CMS)
- Kiểm thử trình duyệt và thiết bị
- Cửa sổ hỗ trợ khởi chạy
Loại trừ:
- Viết nội dung (trừ khi có danh sách công việc khác)
- Hình ảnh stock hoặc phí cấp phép
- Các trang mới ngoài sơ đồ trang web đã được phê duyệt
- Di chuyển SEO trừ khi được xác định trong phạm vi công việc
- Bảo trì liên tục sau khi ra mắt
Mẫu ngôn ngữ trong SOW:
“Nhà cung cấp sẽ thiết kế và phát triển tám trang web dựa trên sơ đồ trang web đã được phê duyệt, với tối đa hai vòng chỉnh sửa cho mỗi trang. Các công việc như viết nội dung, cấp phép hình ảnh stock, yêu cầu thêm trang, chuyển đổi SEO và bảo trì sau khi ra mắt sẽ không được bao gồm trừ khi được phê duyệt thông qua yêu cầu thay đổi bằng văn bản.”
Phạm vi công việc trong xây dựng
Rủi ro trong lĩnh vực xây dựng nằm ở việc cho rằng “quá trình xây dựng” đã bao gồm tất cả các yếu tố liên quan xung quanh công trình. Các vấn đề như giấy phép, kiểm tra, quyền tiếp cận công trường, sự chậm trễ do thời tiết, tăng chi phí vật liệu và các thay đổi thiết kế do chủ đầu tư yêu cầu đều cần được xử lý rõ ràng.
Bao gồm:
- Công việc theo từng giai đoạn, chẳng hạn như phá dỡ, chuẩn bị mặt bằng, lắp khung, điện, nước, hoàn thiện hoặc dọn dẹp
- Vật liệu và thông số kỹ thuật
- Các điểm kiểm tra
- Các cột mốc thanh toán theo tiến độ
- Quy định về việc ra vào công trường
Loại trừ:
- Phí xin giấy phép (trừ khi đã bao gồm)
- Các điều kiện thực tế tại công trường không lường trước được
- Các thay đổi thiết kế do chủ đầu tư yêu cầu
- Cập nhật vật liệu sau khi được phê duyệt
- Thực hiện công việc ngoài phạm vi bản vẽ đã được phê duyệt
Mẫu ngôn ngữ trong SOW:
“Nhà thầu sẽ hoàn thành các công việc chuẩn bị mặt bằng, lắp dựng khung, lắp đặt hệ thống điện thô và hoàn thiện công việc theo bản vẽ và thông số kỹ thuật đã được phê duyệt. Các khoản phí xin giấy phép, các thay đổi theo yêu cầu của chủ đầu tư, các điều kiện mặt bằng không lường trước được và việc nâng cấp vật liệu không được bao gồm trong phạm vi công việc này và sẽ được xử lý thông qua lệnh thay đổi.”
Phạm vi công việc (SOW) cho phát triển phần mềm hoặc sản phẩm
Rủi ro trong lĩnh vực phần mềm nằm ở việc sử dụng ngôn ngữ mô tả tính năng mơ hồ. Cụm từ “Xây dựng bảng điều khiển” có thể mang mười ý nghĩa khác nhau đối với mười bên liên quan. Hãy xác định rõ tính năng, điều kiện kiểm thử, môi trường, trách nhiệm tích hợp và khung thời gian hỗ trợ sau khi ra mắt.
Bao gồm:
- Câu chuyện người dùng hoặc danh sách tính năng
- Yêu cầu chức năng
- Các yêu cầu phi chức năng, chẳng hạn như hiệu suất, bảo mật và khả năng truy cập
- Trách nhiệm liên quan đến API hoặc tích hợp
- Phạm vi kiểm thử và sửa lỗi
- Chuẩn bị và bàn giao sản xuất
Loại trừ:
- Các tính năng nằm ngoài các user story trong Danh sách công việc
- Chi phí cho các công cụ của bên thứ ba
- Làm sạch hoặc di chuyển dữ liệu, trừ khi đã được đưa vào phạm vi công việc
- Các dự án tái thiết kế UX quy mô lớn
- Hỗ trợ sau thời gian bảo hành
Mẫu ngôn ngữ trong SOW:
“Nhà cung cấp sẽ phát triển các câu chuyện người dùng được liệt kê trong Phụ lục A và triển khai chúng lên môi trường thử nghiệm để khách hàng xem xét. Các tính năng nằm ngoài Phụ lục A, phí đăng ký dịch vụ của bên thứ ba, việc dọn dẹp dữ liệu lịch sử và hỗ trợ sau thời hạn bảo hành sẽ không được bao gồm, trừ khi được phê duyệt thông qua yêu cầu thay đổi.”
Phạm vi công việc (SOW) cho chiến dịch tiếp thị
Rủi ro trong tiếp thị nằm ở việc nhầm lẫn giữa các sản phẩm đầu ra (deliverables) với kết quả (outcomes). Bạn có thể xác định phạm vi chiến lược chiến dịch, tài sản tiếp thị, báo cáo và hỗ trợ triển khai. Bạn nên thận trọng khi cam kết về số lượng khách hàng tiềm năng, doanh thu, chi phí thu hút khách hàng (CAC) hoặc tỷ suất lợi nhuận trên chi phí quảng cáo (ROAS), trừ khi nhà cung cấp kiểm soát ngân sách quảng cáo, trang đích, hoạt động theo dõi bán hàng và thiết lập hệ thống đang theo dõi.
Bao gồm:
- Chiến lược chiến dịch
- Đối tượng mục tiêu và thông điệp
- Số lượng ý tưởng quảng cáo hoặc biến thể sáng tạo
- Viết nội dung hoặc thiết kế trang đích
- Nội dung email
- Bảng điều khiển báo cáo
- Tần suất báo cáo
Loại trừ:
- Chi tiêu cho quảng cáo trả phí
- Thiết lập tài khoản quảng cáo (trừ khi có ghi rõ trong danh sách công việc)
- Các biến thể sáng tạo bổ sung
- Phí cho người ảnh hưởng hoặc đối tác
- Theo dõi sau bán hàng
- Các cam kết về hiệu suất nằm ngoài các biện pháp kiểm soát đã thỏa thuận
Mẫu ngôn ngữ trong SOW:
“Nhà cung cấp sẽ cung cấp chiến lược chiến dịch, ba ý tưởng sáng tạo quảng cáo, nội dung trang đích, hai email tiếp thị và bảng điều khiển báo cáo hiệu suất. Chi phí quảng cáo trả phí, phí trả cho người ảnh hưởng, các biến thể sáng tạo bổ sung và hoạt động theo dõi bán hàng không được bao gồm. Các mục tiêu hiệu suất mang tính định hướng trừ khi được liên kết riêng biệt với ngân sách đã được phê duyệt, hệ thống theo dõi và các biện pháp kiểm soát chiến dịch.”
Phạm vi công việc (SOW) cho dịch vụ tư vấn hoặc hợp đồng cố vấn
Rủi ro trong các hợp đồng dịch vụ cố định nằm ở việc không rõ ràng về sức chứa. “Hỗ trợ liên tục” có thể trở thành các cuộc gọi không giới hạn, lập chiến lược, triển khai, báo cáo và các yêu cầu đột xuất, trừ khi tài liệu SOW quy định rõ số giờ làm việc, thời gian phản hồi, tần suất cuộc họp và các quy tắc chuyển tiếp.
Bao gồm:
- Số giờ làm việc hàng tháng hoặc khối lượng sản phẩm đầu ra
- Mong đợi về thời gian phản hồi
- Tần suất cuộc họp
- Tần suất báo cáo
- Người liên hệ chính
- Quy tắc gia hạn hoặc hết hạn
Loại trừ:
- Công việc vượt quá số giờ làm việc hàng tháng
- Hoàn thành trong ngày trừ khi có thỏa thuận khác
- Các dự án chiến lược mới
- Các buổi hội thảo bổ sung dành cho các bên liên quan
- Thực hiện công việc ngoài phạm vi dịch vụ đã ký kết
Mẫu ngôn ngữ trong SOW:
“Nhà cung cấp sẽ cung cấp tối đa 20 giờ hỗ trợ tư vấn mỗi tháng, bao gồm một cuộc gọi tư vấn hàng tuần, xem xét không đồng bộ các tài liệu đã thỏa thuận và bản tóm tắt các khuyến nghị hàng tháng. Số giờ chưa sử dụng sẽ không được chuyển sang tháng sau. Các dự án mới, yêu cầu trong ngày và công việc vượt quá 20 giờ phải có sự chấp thuận bằng văn bản.”
Cách làm hữu ích này áp dụng chung cho mọi ngành nghề: liệt kê các sản phẩm đầu ra, nêu rõ các giả định chung và ghi rõ các trường hợp loại trừ liên quan đến những yêu cầu mà người dùng có khả năng đưa ra sau này.
Cách tiếp cận mới: Hãy coi SOW như một cơ sở để thực hiện công việc, chứ không phải là một tệp PDF đã được lưu trữ
Đến nay, xu hướng đã rõ ràng: một tệp PDF đã có chữ ký không thể theo dõi được một dự án đang thay đổi. Vì vậy, câu hỏi thực sự không phải là làm thế nào để soạn thảo một SOW tốt hơn, mà là SOW sẽ trở thành gì sau khi có chữ ký.
Hãy xem đây là hai phần riêng biệt, không phải một. Thỏa thuận đã ký sẽ được giữ nguyên như một cơ sở tham chiếu, ghi lại những gì cả hai bên đã thống nhất từ đầu. Các nội dung xung quanh nó luôn được cập nhật: công việc, người chịu trách nhiệm, dòng thời gian, phê duyệt, ngân sách, rủi ro và yêu cầu thay đổi. Khi hai phần này được kết nối với nhau, một yêu cầu mới sẽ không thể âm thầm trở thành công việc miễn phí; nó sẽ được hiển thị so với cơ sở tham chiếu dưới dạng một thay đổi.
Điểm khác biệt nằm ở chỗ:
| SOW tĩnh | Bản tham chiếu cơ sở của SOW |
|---|---|
| Dạng tệp PDF hoặc tệp đính kèm | Kết nối với các công việc, dòng thời gian, quy trình phê duyệt và ngân sách |
| Chỉ mở lại khi có sự cố xảy ra | Được tham khảo trong các chu kỳ triển khai và đánh giá |
| Các thay đổi được thực hiện qua Slack, email hoặc các cuộc gọi riêng | Các thay đổi được ghi lại, định giá, phê duyệt và liên kết với tác động đến dòng thời gian |
| Danh sách công việc đã lệch khỏi thỏa thuận ban đầu | Việc thực hiện luôn được theo dõi và tuân thủ phạm vi công việc đã được phê duyệt |
Tài liệu SOW đã được ký kết không nên bị chỉnh sửa một cách tùy tiện mỗi khi có thay đổi. Đây chính là vấn đề "mở rộng công việc" ở quy mô nhỏ, khi bản cập nhật được gửi qua tin nhắn riêng (DM), tài liệu SOW lại nằm trong một tệp riêng biệt, còn danh sách công việc lại nằm ở một nơi khác.
Đây chính là lúc các công cụ như ClickUp phát huy tác dụng. Tài liệu SOW có thể được quản lý cùng với các công việc, bình luận, phê duyệt, thời hạn và ngân sách.
Đoạn video ngắn trên ClickUp này sẽ cho bạn thấy tài liệu đó trông như thế nào và cách các nhóm phối hợp để hoàn thiện nó.
Thực hành tốt nhất: Luôn duy trì phiên bản gốc ổn định và quản lý các thay đổi thông qua nhật ký thay đổi rõ ràng hoặc yêu cầu thay đổi đã được phê duyệt. Ví dụ, nếu khách hàng yêu cầu thêm hai trang đích trong quá trình triển khai chiến dịch, yêu cầu này không nên chỉ đơn thuần xuất hiện trên Bảng dự án. Yêu cầu đó cần được ghi nhận là một thay đổi về phạm vi công việc, được đánh giá về tác động đến chi phí và dòng thời gian, được phê duyệt bằng văn bản, và sau đó mới được bổ sung vào kế hoạch công việc.
Cách quản lý phạm vi công việc trong ClickUp
Việc quản lý SOW sẽ trở nên dễ dàng hơn khi tài liệu, các công việc, quy trình phê duyệt và dòng thời gian được kết nối chặt chẽ với nhau:
Sử dụng ClickUp Docs để soạn thảo SOW ngay tại nơi công việc được thực hiện
Bắt đầu với tài liệu SOW trong ClickUp Docs. Bạn có thể sử dụng tài liệu này để ghi lại mục tiêu, sản phẩm đầu ra, các nội dung không bao gồm, dòng thời gian, tiêu chí chấp nhận và điều khoản thanh toán. Sau đó, khi dự án tiến triển, tài liệu này vẫn có thể được kết nối với các công việc và cột mốc quan trọng mà nó quản lý.
Ví dụ, phần “Kết quả đầu ra” trong SOW của một trang web có thể liên kết với các công việc như nội dung trang chủ, bản phác thảo giao diện (wireframes), đánh giá thiết kế, phát triển, kiểm thử chất lượng (QA) và phê duyệt cuối cùng. Điều này giúp việc tham khảo SOW trở nên dễ dàng hơn trong quá trình triển khai.
Chuyển các sản phẩm đầu ra thành các nhiệm vụ ClickUp và công việc con
Sau khi hoàn thành tài liệu SOW, hãy chuyển từng sản phẩm đầu ra thành một công việc hoặc nhóm các công việc con bằng tính năng nhiệm vụ ClickUp.
Ví dụ, “ba trang đích” có thể được chia thành các công việc riêng biệt cho từng trang. Mỗi trang sau đó có thể có các công việc con liên quan đến nội dung, thiết kế, phát triển, rà soát, kiểm tra chất lượng (QA) và phê duyệt.
Điều này giúp nhóm nhận ra khối lượng công việc thực tế đằng sau mỗi sản phẩm đầu ra. Đồng thời, nó cũng giảm thiểu rủi ro mở rộng phạm vi công việc một cách âm thầm. Nếu một trang đích thứ tư xuất hiện trong danh sách công việc, việc phát hiện ra sẽ dễ dàng hơn vì nó không khớp với SOW ban đầu.
Theo dõi các phạm vi công việc đang thực hiện thông qua các bảng điều khiển thời gian thực
Bảng điều khiển ClickUp sẽ hỗ trợ bạn khi cần quản lý nhiều tài liệu SOW cùng lúc.
Các cơ quan, nhà thầu hoặc nhóm vận hành có thể sử dụng bảng điều khiển để theo dõi các phê duyệt quá hạn, công việc theo từng khách hàng, các cột mốc quan trọng sắp tới, các yêu cầu thay đổi đang chờ xử lý, khối lượng công việc và các tín hiệu liên quan đến ngân sách. Điều này giúp phát hiện rủi ro liên quan đến phạm vi công việc dễ dàng hơn trước khi nó trở thành vấn đề ảnh hưởng đến lợi nhuận.
Ví dụ: nếu có ba dự án của khách hàng đang chờ phản hồi, bảng điều khiển có thể hiển thị tình trạng chậm trễ đó trên các tài khoản thay vì giấu thông tin này trong các danh sách công việc riêng lẻ.
Các Bảng điều khiển (Dashboards) của ClickUp đã thay đổi cách chúng tôi vận hành các hoạt động hàng ngày của công ty. Chúng tôi theo dõi sức chứa của ba nhóm phát triển và phát hiện các rào cản trước khi chúng trở thành nguyên nhân gây chậm trễ, nhờ đó chúng tôi dành ít thời gian hơn để theo dõi trạng thái trong các chủ đề trên Slack và có nhiều thời gian hơn để thực sự thúc đẩy công việc cho khách hàng.
Các Bảng điều khiển (Dashboards) của ClickUp đã thay đổi cách chúng tôi vận hành các hoạt động hàng ngày của công ty. Chúng tôi theo dõi sức chứa của ba nhóm phát triển và phát hiện các rào cản trước khi chúng trở thành nguyên nhân gây chậm trễ, nhờ đó chúng tôi dành ít thời gian hơn để theo dõi trạng thái trong các chủ đề trên Slack và có nhiều thời gian hơn để thực sự thúc đẩy công việc cho khách hàng.
Soạn thảo, tóm tắt và kiểm tra ngữ cảnh với ClickUp Brain
ClickUp Brain có thể soạn thảo tài liệu SOW dựa trên bản tóm tắt dự án, tóm tắt các cuộc gọi dài với khách hàng, chuyển đổi ghi chú thành slide hoặc trả lời các câu hỏi bằng cách sử dụng dữ liệu của nhóm từ các công việc, tài liệu, trò chuyện và các không gian làm việc được kết nối.
Đối với SOW, điều đó có nghĩa là bạn có thể đặt các câu hỏi như:
- “Những sản phẩm nào vẫn đang chờ sự phê duyệt của khách hàng?”
- “Những công việc nào đã được bổ sung sau bản SOW ban đầu?”
- “Tóm tắt các yêu cầu thay đổi đang chờ xử lý của khách hàng này.”
- “Soạn thảo các tiêu chí chấp nhận dựa trên các sản phẩm đầu ra này.”
Brain còn mở rộng hướng tiếp cận dựa trên ngữ cảnh này hơn nữa, với trí tuệ nhân tạo (AI) được xây dựng dựa trên các dự án, tài liệu, nhân sự, cuộc hội thoại và kiến thức của công ty.
Hãy để Super Agents thực hiện các kiểm tra phạm vi công việc định kỳ
Các Super Agents sẽ phát huy hiệu quả hơn khi quy trình đã được xác định rõ ràng.
Ví dụ: một nhóm có thể cài đặt một công việc tự động để chuẩn bị bản đánh giá phạm vi công việc hàng tuần, tổng hợp các phê duyệt quá hạn, đánh dấu các công việc chưa có trạng thái trong phạm vi công việc hoặc soạn thảo bản cập nhật cho khách hàng trước cuộc họp về cột mốc.
Một trường hợp sử dụng điển hình là:
“Mỗi thứ Sáu, hãy tổng hợp tất cả các yêu cầu thay đổi đang chờ xử lý, các công việc được thêm vào trong tuần này, các phê duyệt bị trì hoãn và các cột mốc quan trọng có nguy cơ bị ảnh hưởng trong dự án của khách hàng này.” Điều này giúp người quản lý dự án có chu trình rà soát nhanh hơn. Tuy nhiên, điều này không nên thay thế cho việc phê duyệt chính thức. Bất kỳ công việc bổ sung nào vẫn cần có sự phê duyệt bằng văn bản trước khi được đưa vào phạm vi công việc.
Giới hạn thực tế
ClickUp đặc biệt hữu ích trong những trường hợp sự thay đổi phạm vi công việc gây ra chi phí thực tế: các cơ quan, nhóm dịch vụ, nhà thầu, chuyên gia tư vấn, nhóm vận hành và các nhóm nội bộ đang quản lý nhiều dự án cùng lúc.
Đối với một freelancer làm việc độc lập đang soạn thảo một bản SOW dài một trang cho một dự án đơn giản, cấu trúc này có thể là quá phức tạp so với nhu cầu thực tế. Một tài liệu gọn gàng, danh sách công việc được chia sẻ và văn bản phê duyệt có chữ ký có thể là đủ.
Lợi ích thực sự chỉ xuất hiện khi SOW không còn chỉ là một tài liệu đơn thuần. Nó trở thành cơ sở để nhóm của bạn kết nối với các công việc, dòng thời gian, quy trình phê duyệt, yêu cầu thay đổi và giao tiếp với khách hàng.
Những sai lầm thường gặp trong phạm vi công việc cần tránh
| Lỗi | Tại sao điều này lại gây ra vấn đề | Sửa |
|---|---|---|
| Các sản phẩm đầu ra không rõ ràng | Các từ như “quản lý”, “hỗ trợ” hoặc “tối ưu hóa” có thể được hiểu theo nhiều cách khác nhau khi không kèm theo số lượng hoặc phạm vi cụ thể | Đặt tên cho sản phẩm đầu ra, thêm số thứ tự và xác định quy trình bàn giao |
| Không có danh sách loại trừ | Bất kỳ nội dung nào không được nêu rõ đều có thể được coi là đã được bao gồm, đặc biệt trong công việc dịch vụ dành cho khách hàng | Thêm một phần " Ngoài phạm vi công việc " dành cho các công việc liên quan mà khách hàng có thể hợp lý kỳ vọng |
| Đếm số lần sửa đổi mà không định nghĩa khái niệm "sửa đổi" | “Hai vòng” vẫn có thể trở nên rối rắm nếu một vòng bao gồm mười thay đổi không liên quan từ năm bên liên quan | Xác định nội dung của một vòng sửa đổi, ai có thể yêu cầu và khi nào vòng sửa đổi đó kết thúc |
| Không có quy trình kiểm soát thay đổi | Mỗi yêu cầu mới đều trở thành một cuộc đàm phán không chính thức ngay khi công việc đã bắt đầu | Yêu cầu phải có sự chấp thuận bằng văn bản đối với bất kỳ thay đổi nào về phạm vi công việc, bao gồm cả những thay đổi ảnh hưởng đến chi phí và dòng thời gian. |
| Bỏ qua các yếu tố phụ thuộc từ phía khách hàng | Phản hồi chậm trễ, thiếu tệp tin hoặc việc phê duyệt bị trì hoãn có thể làm thay đổi dòng thời gian dự án, trong khi nhà cung cấp lại phải gánh chịu trách nhiệm | Nêu rõ những gì khách hàng phải cung cấp, thời hạn cụ thể và cách thức mà sự chậm trễ ảnh hưởng đến thời hạn giao hàng |
Biến phạm vi công việc của bạn thành một hệ thống linh hoạt
Một SOW tốt mang lại lợi ích gấp ba lần. Việc soạn thảo nó buộc các phần mơ hồ phải trở nên cụ thể. Trong quá trình triển khai dự án, nó giúp giải quyết tranh chấp trước khi chúng leo thang. Và khi phạm vi công việc bị mở rộng ngoài dự kiến, nó giúp hiển thị những thay đổi đó thay vì để chúng lọt qua mà không được kiểm soát.
Tuy nhiên, tất cả những giá trị đó chỉ có ý nghĩa nếu đáp ứng một điều kiện: tài liệu không được bị bỏ quên trong hộp thư đến.
Các nhóm tận dụng tối đa tài liệu này coi phạm vi công việc như một hệ thống linh hoạt: được định nghĩa rõ ràng ngay từ đầu, kết nối với các công việc thực tế và được điều chỉnh theo sự phát triển của công việc. Hãy bao quát bảy thành phần, định lượng từng sản phẩm đầu ra, nêu rõ các nội dung không bao gồm và đảm bảo tài liệu luôn gắn liền với công việc mà nó mô tả.
Cách nhanh nhất để áp dụng điều này vào thực tế là bắt đầu từ một mẫu có sẵn và kết nối nó với dự án của bạn. Bắt đầu sử dụng ClickUp miễn phí, tùy chỉnh Mẫu SOW trong tài liệu, sau đó kết nối từng sản phẩm đầu ra với các công việc thực hiện chúng.
Các câu hỏi thường gặp về phạm vi công việc
Sự khác biệt giữa phạm vi công việc và phạm vi dự án là gì?
Phạm vi công việc là tài liệu xác định các sản phẩm đầu ra và công việc cho một dự án cụ thể hoặc một giai đoạn nhất định. Phạm vi dự án là khái niệm kế hoạch rộng hơn, xác định ranh giới toàn diện của dự án: bao gồm mọi thứ và loại trừ mọi thứ. Nói tóm lại, phạm vi công việc mô tả một phần công việc, trong khi phạm vi dự án mô tả toàn bộ ranh giới mà công việc đó nằm trong đó.
Sự khác biệt giữa phạm vi công việc và thỏa thuận dịch vụ tổng thể (MSA) là gì?
Hợp đồng khung (MSA) quy định các điều khoản pháp lý và thương mại tổng thể điều chỉnh mối quan hệ khách hàng - nhà cung cấp đang diễn ra; trong khi đó, phạm vi công việc (SOW) xác định các sản phẩm đầu ra cho một dự án cụ thể trong khuôn khổ đó. Cấu trúc phân cấp điển hình là MSA ở cấp cao nhất, các bản mô tả công việc riêng lẻ nằm dưới MSA, và phạm vi công việc được lồng ghép bên trong mỗi bản mô tả công việc. Hợp đồng khung (MSA) chỉ được ký một lần; một bản mô tả công việc (SOW) mới sẽ được ban hành cho mỗi dự án.
Có bốn loại phạm vi công việc nào?
Bốn cấu trúc phổ biến bao gồm: dựa trên sản phẩm đầu ra (thanh toán gắn liền với các sản phẩm cụ thể), theo thời gian và vật liệu (tính phí theo giờ và chi phí trong quá trình thực hiện công việc), mức độ nỗ lực (một mức sức chứa cố định trong một kỳ, thường áp dụng cho các hợp đồng cố định), và dựa trên hiệu suất (thanh toán gắn liền với các kết quả có thể đo lường được). Hãy chọn cấu trúc phù hợp với mức độ dự đoán được của các sản phẩm đầu ra. Hầu hết các tranh chấp về phạm vi công việc đều bắt nguồn từ việc cấu trúc không phù hợp với công việc.
Ai là người soạn thảo phạm vi công việc?
Bên thực hiện công việc thường là người soạn thảo phạm vi công việc: công ty đại diện, nhà cung cấp hoặc người phụ trách dự án nội bộ. Sau đó, cả hai bên sẽ xem xét và ký xác nhận trước khi bắt đầu công việc. Việc tự soạn thảo tài liệu này mang lại lợi thế vì giúp bạn xác định các sản phẩm đầu ra, phạm vi công việc và các nội dung không bao gồm theo điều kiện của riêng bạn.
Phạm vi công việc có giá trị pháp lý không?
Phạm vi công việc sẽ có hiệu lực pháp lý ngay khi được ký kết như một phần của hợp đồng hoặc bản mô tả công việc. Khi đứng riêng lẻ, tài liệu này chủ yếu định nghĩa công việc cần thực hiện, nhưng khi nằm trong một thỏa thuận đã ký kết, nó trở thành cơ sở tham chiếu cho những cam kết đã được đưa ra. Đối với bất kỳ thỏa thuận hợp đồng nào, hãy nhờ một chuyên gia có trình độ chuyên môn rà soát các điều khoản ràng buộc.
Phạm vi công việc có thể được sử dụng cho các dự án nội bộ không?
Đúng vậy. Phạm vi công việc được áp dụng giữa các nhóm nội bộ — chẳng hạn như bộ phận tiếp thị yêu cầu phát triển một bảng điều khiển dữ liệu, hoặc bộ phận vận hành yêu cầu một công cụ nội bộ — cũng giống hệt như khi áp dụng giữa khách hàng và nhà cung cấp. Các thành phần đều giống nhau: mục tiêu, sản phẩm đầu ra, dòng thời gian, tiêu chí chấp nhận và các nội dung không bao gồm. Điểm khác biệt duy nhất là việc phê duyệt đến từ các bên liên quan nội bộ thay vì khách hàng bên ngoài, và các điều khoản thanh toán có thể được thay thế bằng ngân sách hoặc phân bổ nguồn lực.
Có từ nào khác để chỉ "phạm vi công việc" không?
Phạm vi công việc đôi khi còn được gọi là bản mô tả công việc, bản mô tả phạm vi dự án hoặc đơn giản là “phạm vi”, mặc dù đây không phải là những từ đồng nghĩa hoàn hảo. Bản mô tả công việc là hợp đồng có phạm vi rộng hơn; bản mô tả phạm vi dự án là phiên bản kế hoạch nội bộ. Nếu ai đó sử dụng các thuật ngữ này một cách không chính xác, hãy xác nhận xem họ đang đề cập đến các sản phẩm đầu ra (phạm vi công việc) hay toàn bộ thỏa thuận (bản mô tả công việc) trước khi bạn thực hiện theo đó.
Sự khác biệt giữa phạm vi công việc và cấu trúc phân chia công việc (WBS) là gì?
Phạm vi công việc (SOW) nêu rõ những gì sẽ được bàn giao và các điều khoản liên quan; trong khi đó, cấu trúc phân chia công việc (WBS) chia các sản phẩm đầu ra đó thành một hệ thống phân cấp gồm các sản phẩm đầu ra phụ và các công việc. SOW là thỏa thuận; WBS là bản đồ thực thi chi tiết bên dưới nó. Bạn xây dựng WBS dựa trên các sản phẩm đầu ra của SOW, nhờ đó tài liệu này luôn có kết nối với các công việc thực tế thay vì bị lệch hướng.