Quản trị dự án #01: Hiểu đúng về dự án, xác định phạm vi và xây dựng WBS trước khi bắt đầu

Lời mở đầu: Làm nhiều việc không đồng nghĩa với quản lý dự án tốt

Hãy tưởng tượng bạn đang phụ trách một dự án Marketing có thời gian triển khai hai tháng. Đội ngũ đã lên kế hoạch, phân chia công việc và bắt đầu thực hiện. Nhưng sau cuộc họp với khách hàng, bạn nhận được một yêu cầu mới:

Nghe có vẻ chỉ là thay đổi deadline. Nhưng với người quản lý dự án, đây là một vấn đề lớn hơn nhiều.

Nếu rút ngắn thời gian, liệu đội ngũ có đủ nguồn lực thực hiện? Có hạng mục nào bắt buộc phải hoàn thành trước hạng mục khác? Chất lượng đầu ra sẽ bị ảnh hưởng thế nào? Và quan trọng nhất, có nên đồng ý với yêu cầu này ngay lập tức?

Tình huống trên là một trong những bài toán được đặt ra trong Buổi 1 của khóa học Quản lý dự án tại SEONGON Academy. Nó cũng phản ánh một thực tế phổ biến trong công việc: chúng ta thường rất nhanh bắt đầu thực hiện, nhưng lại chưa dành đủ thời gian để xác định phạm vi, thống nhất kỳ vọng và làm rõ các ràng buộc.

Đó là lý do tôi bắt đầu series này bằng hai câu hỏi:

1. Quản trị dự án thực chất là quản trị điều gì?
2. Làm thế nào để xác định rõ phạm vi công việc trước khi triển khai?

Bài viết là phần đầu tiên trong series 7 bài về Quản trị dự án, được tôi tổng hợp và diễn giải từ tài liệu học tập của SEONGON Academy, kết hợp với những ví dụ ứng dụng trong Marketing và công việc. Mục tiêu của series không chỉ là giải thích thuật ngữ, mà là giúp chúng ta từng bước hình thành tư duy tổ chức, triển khai và kiểm soát dự án một cách bài bản hơn.

01. Quản trị dự án là gì? Trước hết, cần hiểu đúng về một dự án

Trong công việc, chúng ta thường sử dụng từ “dự án” khá rộng rãi. Một chiến dịch quảng cáo được gọi là dự án. Xây dựng website được gọi là dự án. Thậm chí, đôi khi cả công việc đăng bài hằng ngày cũng được gọi như vậy.

Tuy nhiên, không phải mọi công việc đều là một dự án.

Theo cách tiếp cận trong giáo trình, dự án (Project) là một nhóm công việc có điểm bắt đầu, điểm kết thúc và hướng đến việc tạo ra một kết quả mang tính riêng biệt. Ngược lại, vận hành (Operation) là những công việc diễn ra liên tục hoặc lặp lại, tập trung vào duy trì, cải thiện và tối ưu hoạt động đã có.

Phân biệt Project và Operation

Hãy lấy hai tình huống quen thuộc trong Marketing:

Tình huống A: Quản lý nội dung Facebook hằng ngày. Một thương hiệu đăng bài thường xuyên, theo dõi tương tác, trả lời bình luận và tối ưu nội dung theo tuần. Đây chủ yếu là hoạt động vận hành (Operation).

Tình huống B: Triển khai chiến dịch ra mắt dòng sản phẩm mới. Đội ngũ có thời điểm bắt đầu, ngày ra mắt, ngân sách, danh sách hạng mục, bộ nội dung cần sản xuất và mục tiêu cụ thể. Đây là một dự án (Project).

Tương tự, việc chạy quảng cáo duy trì và tối ưu hằng tuần có tính vận hành, còn một chiến dịch quảng cáo Tết kéo dài sáu tuần với mục tiêu, ngân sách và kế hoạch riêng có thể được quản lý như một dự án.

02. Một dự án thường trải qua những giai đoạn nào?

Tài liệu Buổi 1 giới thiệu năm giai đoạn cơ bản của một dự án theo chuẩn quản trị quốc tế:

Giai đoạn 1: Khởi tạo — Initiating

Đây là lúc xác định vì sao dự án cần được thực hiện. Những câu hỏi quan trọng gồm:

• Dự án cần giải quyết vấn đề kinh doanh gì?
• Mục tiêu mong muốn cụ thể là gì?
• Ai là người yêu cầu hoặc phê duyệt dự án?
• Những bên liên quan nào sẽ tham gia?
• Dự án có khả thi với các điều kiện ban đầu không?

Ví dụ, một doanh nghiệp muốn xây dựng website mới vì website hiện tại chưa hỗ trợ tốt việc giới thiệu sản phẩm và tiếp nhận thông tin khách hàng. Ở giai đoạn khởi tạo, đội ngũ cần hiểu bài toán kinh doanh này trước khi bàn về màu sắc, bố cục hay hiệu ứng giao diện.

Giai đoạn 2: Lập kế hoạch — Planning

Khi đã biết dự án hướng đến điều gì, bước tiếp theo là xác định cách đạt được mục tiêu. Đội ngũ cần làm rõ phạm vi công việc, sản phẩm bàn giao, tiến độ, nguồn lực, ngân sách, yêu cầu chất lượng và các rủi ro có thể gặp.

Một kế hoạch tốt không chỉ nói khi nào làm, mà còn chỉ ra cần hoàn thành những gì và trong điều kiện nào.

Giai đoạn 3: Thực thi — Executing

Đây là giai đoạn đội ngũ triển khai công việc theo kế hoạch. Ví dụ với dự án website: nghiên cứu yêu cầu, thiết kế giao diện, phát triển tính năng, chuẩn bị nội dung, kiểm thử và hoàn thiện sản phẩm. Project Manager cần điều phối công việc và hỗ trợ xử lý những vấn đề phát sinh để các phần việc không bị tách rời.

Giai đoạn 4: Giám sát và kiểm soát — Monitoring & Controlling

Giám sát không có nghĩa là đợi đến khi dự án gần kết thúc mới kiểm tra. Hoạt động này cần diễn ra xuyên suốt quá trình triển khai. Người quản lý phải liên tục so sánh kết quả thực tế với kế hoạch, nhận diện chênh lệch và điều chỉnh khi cần.

Một số câu hỏi nên được kiểm tra thường xuyên:

• Có đầu việc nào chậm tiến độ không?
• Có yêu cầu mới nào phát sinh ngoài kế hoạch?
• Chất lượng đầu ra đã đáp ứng tiêu chí nghiệm thu chưa?
• Chi phí hoặc nguồn lực có bị đội lên không?
• Có vấn đề nào cần được các bên liên quan quyết định ngay?

Giai đoạn 5: Đóng dự án — Closing

Hoàn thành công việc không đồng nghĩa với việc dự án đã được đóng. Một dự án cần có quá trình nghiệm thu, bàn giao, tổng kết và xác nhận hoàn thành chính thức.

Ví dụ, một website đã xuất hiện trên Internet chưa chắc đã được nghiệm thu nếu form liên hệ không hoạt động, tài liệu bàn giao còn thiếu hoặc khách hàng chưa phê duyệt.

Điểm cần nhớ: Một dự án không chỉ cần được triển khai. Nó cần được khởi tạo đúng, lập kế hoạch rõ, kiểm soát thường xuyên và kết thúc có xác nhận.

03. Vì sao quản lý dự án lại quan trọng?

Một dự án không tồn tại trong môi trường hoàn toàn ổn định. Ngay cả khi kế hoạch ban đầu rất tốt, kết quả vẫn có thể bị ảnh hưởng bởi nhiều yếu tố. Giáo trình phân chia những yếu tố này thành hai nhóm:

Nhóm 1: Các yếu tố bên trong dự án

Đây là những yếu tố người quản lý thường có khả năng kiểm soát hoặc tác động trực tiếp nhiều hơn:

• Phạm vi công việc chưa rõ hoặc liên tục bị mở rộng tự phát.
• Tiến độ, ngân sách và yêu cầu chất lượng không thực tế.
• Nguồn lực và năng lực của đội ngũ chưa khớp với bài toán.
• Kỳ vọng giữa các bên (khách hàng, ban giám đốc, đội ngũ) không thống nhất.
• Khả năng phối hợp và giao tiếp nội bộ kém.
• Mức độ cam kết và hỗ trợ từ cấp quản lý.

Ví dụ: Designer đã hoàn thành giao diện nhưng bộ phận Content chưa cung cấp nội dung, khiến công việc phát triển website bị chậm. Vấn đề này không nhất thiết đến từ việc một cá nhân làm việc thiếu trách nhiệm. Nó có thể xuất phát từ cách tổ chức công việc, xác định sự phụ thuộc (Dependencies) và phối hợp giữa các vị trí.

Nhóm 2: Các yếu tố bên ngoài dự án

Đây là những yếu tố đội ngũ khó kiểm soát trực tiếp:

• Biến động thị trường hoặc sự thay đổi chiến lược của đối thủ cạnh tranh.
• Yêu cầu pháp lý, quy định ngành và quy trình kiểm duyệt nội dung.
• Thay đổi thuật toán nền tảng (Facebook, TikTok, Google) hoặc công nghệ.
• Nhà cung cấp, KOLs, đối tác hoặc bên thứ ba bàn giao chậm.

Ví dụ: Một chiến dịch đã có lịch xuất bản nhưng đối tác sản xuất video bàn giao chậm hoặc nền tảng quảng cáo thay đổi chính sách kiểm duyệt. Người quản lý không thể loại bỏ hoàn toàn những yếu tố này. Tuy nhiên, họ có thể chủ động nhận diện, dự phòng và xây dựng phương án ứng phó.

Đó cũng là một trong những lý do cần quản trị dự án bài bản: để giảm sự phụ thuộc vào may mắn và tăng khả năng chủ động trước những thay đổi.

04. Project Manager thực sự làm gì?

Khi nhắc đến Project Manager (PM), nhiều người hình dung đây là người lập danh sách việc cần làm, phân công nhân sự và liên tục nhắc deadline. Nhưng vai trò của PM rộng hơn như vậy rất nhiều.

Theo giáo trình SEONGON Academy, Project Manager có hai trách nhiệm cốt lõi:

Điểm đáng chú ý là PM không nhất thiết phải trực tiếp làm giỏi nhất mọi công việc chuyên môn trong dự án.

Trong một dự án Marketing, PM không bắt buộc phải là người thiết kế đẹp nhất, viết nội dung hay nhất hay chạy quảng cáo kỹ thuật sâu nhất. Điều quan trọng là PM cần hiểu đủ về công việc, biết kết nối các thành viên, làm rõ yêu cầu, nhận diện rủi ro và hỗ trợ đội ngũ hoàn thành mục tiêu chung.

Một ngày làm việc của PM có thể diễn ra như thế nào?

Tài liệu minh họa một ngày làm việc với những hoạt động tiêu biểu:

• Rà soát công việc đầu ngày: Kiểm tra tiến độ tổng thể, cập nhật công cụ quản lý dự án (Jira, Trello, Notion).
• Họp Daily Standup nhanh (15 phút): Đồng bộ công việc với đội ngũ: Hôm qua làm gì? Hôm nay làm gì? Đang gặp rào cản (Blocker) nào?
• Xử lý các điểm nghẽn: Giải quyết tình trạng thiếu thông tin, làm rõ brief với khách hàng hoặc yêu cầu duyệt từ các bên.
• Giao tiếp với các bên liên quan: Báo cáo tiến độ cho cấp trên hoặc khách hàng, duy trì sự minh bạch về tình trạng dự án.
• Kiểm soát rủi ro: Đánh giá nguy cơ chậm tiến độ, đội chi phí hoặc lỗi chất lượng trước khi nó trở thành khủng hoảng.
• Tổng hợp & Thống nhất bước tiếp theo: Ghi chép quyết định quan trọng, cập nhật kế hoạch và phân bổ ưu tiên cho ngày làm việc kế tiếp.

Qua đó, có thể thấy một phần rất lớn công việc của PM nằm ở giao tiếp, điều phối và ra quyết định, thay vì trực tiếp xử lý tất cả đầu việc chuyên môn.

Theo tôi, đây là một sự thay đổi tư duy quan trọng đối với những người bắt đầu đảm nhiệm vai trò quản lý. Khi còn là người thực thi, chúng ta thường được đánh giá thông qua phần việc cá nhân hoàn thành. Nhưng khi quản lý dự án, điều cần quan tâm là liệu cả đội ngũ có đang cùng tiến đến một kết quả chung hay không.

05. Tam giác ràng buộc: Vì sao không thể tùy tiện thay đổi deadline?

Quay trở lại tình huống ở đầu bài: Khách hàng muốn rút ngắn thời gian dự án từ hai tháng xuống một tháng, nhưng không thay đổi phạm vi, ngân sách hoặc nhân sự.

Để phân tích tình huống này, giáo trình giới thiệu Tam giác ràng buộc trong quản lý dự án (Iron Triangle / Triple Constraint).

Ba yếu tố chính gồm:

Ba yếu tố này có quan hệ chặt chẽ với nhau, đồng thời ảnh hưởng trực tiếp đến Chất lượng (Quality) của sản phẩm đầu ra.

Ví dụ, nếu yêu cầu rút ngắn thời gian nhưng vẫn giữ nguyên khối lượng công việc, đội ngũ có thể cần bổ sung nguồn lực (tăng Cost), thay đổi cách tổ chức hoặc chấp nhận một số đánh đổi. Nếu không được bổ sung bất kỳ nguồn lực nào mà vẫn ép giảm một nửa thời gian, chất lượng kiểm thử sẽ bị bỏ qua, nhân sự kiệt sức và tỷ lệ lỗi sẽ tăng vọt.

PM nên xử lý tình huống ra sao?

Thay vì đồng ý ngay theo quán tính, một Project Manager bài bản sẽ tiếp cận theo trình tự 5 bước:

• Bước 1 — Làm rõ lý do thay đổi: Vì sao khách hàng cần hoàn thành sớm hơn? Có một sự kiện kinh doanh bắt buộc (hội chợ, chiến dịch bán lẻ ngày lễ) hay chỉ là mong muốn chủ quan muốn đẩy nhanh tiến độ?
• Bước 2 — Đánh giá phần việc còn lại: Những hạng mục nào chưa hoàn thành? Công việc nào phụ thuộc vào công việc khác? Có hạng mục nào có thể triển khai song song (Fast-tracking) không?
• Bước 3 — Phân tích tác động (Impact Analysis): Việc rút ngắn thời gian ảnh hưởng đến chi phí phát sinh (làm thêm giờ, thuê thêm dev/designer), chất lượng sản phẩm và những cam kết nào?
• Bước 4 — Đưa ra các phương án lựa chọn:
  • Phương án A: Giữ nguyên toàn bộ phạm vi và thời gian cũ theo hợp đồng.
  • Phương án B: Rút ngắn thời gian bằng cách bổ sung nguồn lực (tăng ngân sách) nếu thị trường cho phép.
  • Phương án C: Chia thành hai đợt bàn giao (Phased Release), ưu tiên phiên bản MVP với các hạng mục thiết yếu cho ngày ra mắt, các tính năng phụ sẽ cập nhật sau.
  • Phương án D: Giảm một phần phạm vi công việc và điều chỉnh tiêu chí nghiệm thu nếu các bên đồng thuận.
• Bước 5 — Thống nhất phương án mới trước khi thực hiện: Khi phương án điều chỉnh được phê duyệt bằng văn bản, toàn bộ kế hoạch, phạm vi và ngân sách mới được cập nhật tương ứng.

06. Waterfall, Agile và Hybrid: Chọn cách quản lý dự án phù hợp

Bên cạnh tư duy quản lý, tài liệu giới thiệu ba cách tiếp cận phổ biến: Waterfall, Agile và Hybrid. Không có một phương pháp nào là “thần thánh” phù hợp cho mọi bài toán.

Waterfall — Triển khai tuần tự

Waterfall tổ chức công việc theo các giai đoạn kế tiếp nhau như một dòng thác: giai đoạn trước xong xuôi và được phê duyệt thì giai đoạn sau mới bắt đầu. Toàn bộ kế hoạch tổng thể được xây dựng chi tiết từ sớm.

Phương pháp này phù hợp khi yêu cầu đã được xác định rất cụ thể và ít biến động. Ví dụ: tổ chức một sự kiện có lịch cố định, sản xuất các hạng mục in ấn ấn phẩm theo thiết kế đã duyệt, hoặc triển khai xây dựng văn phòng.

Ưu điểm: Rất dễ quản lý mốc tiến độ, minh bạch trách nhiệm và dự toán chi phí chính xác. Hạn chế: Kém linh hoạt; nếu yêu cầu thay đổi ở giai đoạn cuối, việc điều chỉnh sẽ cực kỳ tốn kém và mất thời gian.

Agile — Triển khai lặp và cải tiến

Agile tập trung vào những vòng làm việc ngắn (Sprints, thường từ 1 đến 3 tuần), tạo ra kết quả từng phần có thể sử dụng được và dùng phản hồi thực tế của người dùng để liên tục điều chỉnh.

Thay vì cố đoán định mọi chi tiết ngay từ đầu, đội ngũ hoàn thiện dần sản phẩm qua từng vòng lặp. Ví dụ: phát triển ứng dụng di động, thử nghiệm tính năng giao diện website hoặc xây dựng một định dạng nội dung mới trên mạng xã hội cần đo lường phản ứng người xem.

Ưu điểm: Linh hoạt cao, nhận phản hồi sớm từ thị trường, giảm nguy cơ đi sai hướng trong thời gian dài. Lưu ý: Agile đòi hỏi tính tự chủ và kỷ luật rất cao từ đội ngũ; Agile hoàn toàn không có nghĩa là làm việc tùy tiện, thiếu kiểm soát hay không có kế hoạch.

Hybrid — Kết hợp tính ổn định và linh hoạt

Hybrid kết hợp kế hoạch tổng thể có cấu trúc ổn định (theo tư duy Waterfall) với cách triển khai linh hoạt ở những phần công việc cần thử nghiệm (theo tư duy Agile).

Ví dụ: Một chiến dịch Marketing có ngày phát động cố định, ngân sách chốt cứng và những hạng mục bàn giao bắt buộc (Key Deliverables). Các yếu tố cốt lõi này cần được quản lý theo mốc chặt chẽ. Nhưng trong quá trình sản xuất nội dung, đội ngũ có thể chia thành các vòng sprint nhỏ để thử nghiệm nhiều phương án sáng tạo, thông điệp hoặc góc tiếp cận khác nhau nhằm chọn ra phương án tối ưu nhất.

Bảng so sánh nhanh

Bài học rút ra: Đừng chọn phương pháp quản lý chỉ vì nó đang là “mốt” hay nghe thời thượng. Hãy chọn dựa trên đặc điểm dự án, mức độ rõ ràng của yêu cầu và mức độ biến động thực tế.

07. Scope là gì và tại sao phải xác định rõ ngay từ đầu?

Hãy tưởng tượng một khách hàng nói với bạn:

Nghe qua, yêu cầu có vẻ tương đối rõ ràng. Nhưng nếu bắt đầu thực hiện ngay, bạn sẽ lập tức rơi vào một mê cung câu hỏi:

• “Hiện đại” nghĩa là phong cách nào? Tối giản (Minimalist), công nghệ (Cyberpunk), hay sang trọng (Luxury)?
• Website có tổng cộng bao nhiêu trang? Ai là người viết nội dung và chụp ảnh sản phẩm?
• “Chuẩn SEO” gồm những công việc cụ thể nào? Cấu trúc URL, thẻ meta, tốc độ tải trang, hay cả nghiên cứu từ khóa và viết 30 bài content chuẩn SEO?
• Có cần chức năng đa ngôn ngữ không? Có cần kết nối CRM hay bảo trì sau bàn giao không?

Chỉ một yêu cầu ngắn đã có thể được hiểu theo hàng chục cách khác nhau. Đó chính là bài toán của Phạm vi công việc (Scope).

Trong quản lý dự án, Scope (phạm vi) giúp xác định những gì dự án cần tạo ra và toàn bộ những công việc cần thực hiện để tạo ra kết quả đó. Tài liệu Buổi 1 phân biệt hai khái niệm quan trọng:

Product Scope — Phạm vi sản phẩm

Trả lời câu hỏi: Dự án sẽ tạo ra sản phẩm hoặc kết quả đầu ra cụ thể gì?

Với một dự án website, Product Scope bao gồm:

• Trang chủ (Homepage) với các khối thông tin theo wireframe.
• Trang giới thiệu dịch vụ và hồ sơ năng lực.
• Hệ thống Blog (Trang danh sách bài viết & Trang chi tiết bài viết).
• Trang liên hệ tích hợp form gửi thông tin vào email quản trị.
• Các tính năng và đặc tính kỹ thuật đã thống nhất (responsive, tối ưu tốc độ).

Đây là những thứ hữu hình mà người sử dụng hoặc khách hàng có thể nhìn thấy, bấm vào, trải nghiệm và nghiệm thu.

Project Scope — Phạm vi dự án

Trả lời câu hỏi: Cần thực hiện những công việc gì để tạo ra sản phẩm đó?

Project Scope bao gồm toàn bộ các phần việc từ đầu đến cuối:

• Thu thập, phân tích và thống nhất bản mô tả yêu cầu.
• Nghiên cứu kiến trúc thông tin (Information Architecture) và vẽ Sitemap.
• Thiết kế Wireframe và hoàn thiện giao diện UI/UX trên Figma.
• Lập trình giao diện Frontend và tính năng Backend.
• Tối ưu SEO on-page theo phạm vi đã chốt trong hợp đồng.
• Kiểm thử giao diện (UI Testing), kiểm thử chức năng (Function Testing) và sửa lỗi.
• Tổ chức các buổi họp review, lấy phê duyệt chính thức từng mốc.
• Đóng gói mã nguồn, triển khai lên hosting và đào tạo hướng dẫn quản trị.

08. Scope Creep: Vì sao dự án càng làm càng phát sinh việc?

Một trong những hiện tượng phổ biến và nguy hiểm nhất được nhấn mạnh trong Buổi 1 là Scope Creep (Phạm vi leo thang).

Scope Creep xảy ra khi phạm vi dự án âm thầm mở rộng dần qua các yêu cầu phát sinh nhỏ lẻ không được đánh giá tác động, ghi nhận và phê duyệt chính thức.

Ví dụ: Dự án website ban đầu chỉ thống nhất 5 loại trang cơ bản. Trong quá trình làm, khách hàng đề nghị:

• “Thêm giúp anh một trang tuyển dụng nhỏ nhé, chắc không mất bao nhiêu thời gian đâu.”
• “Chỉnh lại hiệu ứng này một chút, cho nó động và 3D hơn.”
• “Bổ sung thêm chức năng chatbot AI để tự động trả lời khách hàng vào ban đêm được không em?”

Mỗi yêu cầu riêng lẻ trông có vẻ rất nhỏ và “vô hại”. Nhưng khi cộng dồn hàng chục yêu cầu như vậy, chúng sẽ làm vỡ nát kế hoạch ban đầu, khiến dự án chậm tiến độ nghiêm trọng, ngân sách bị thâm hụt và đội ngũ kiệt sức.

Phân biệt Scope Creep và Gold Plating

Hai khái niệm này đều tạo ra phần việc vượt quá thỏa thuận ban đầu, nhưng nguồn gốc xuất phát hoàn toàn khác nhau:

Gold Plating thường xuất phát từ ý tốt — mong muốn sản phẩm hoàn hảo nhất có thể. Tuy nhiên, nếu phần bổ sung đó ngốn thêm nguồn lực, làm chậm tiến độ tổng thể hoặc gây phát sinh lỗi tương thích, nó sẽ trở thành một rủi ro lớn cho dự án.

Ghi nhớ: Làm tốt không đồng nghĩa với làm càng nhiều càng tốt. Làm tốt là tạo ra kết quả đáp ứng chuẩn xác mục tiêu và tiêu chí đã được các bên thống nhất.

09. Quy trình quản lý Scope gồm bốn bước

Để kiểm soát phạm vi một cách khoa học, giáo trình SEONGON Academy đưa ra quy trình quản trị Scope tiêu chuẩn gồm 4 bước:

Để giúp bạn dễ hình dung và áp dụng, tôi sẽ sử dụng một ví dụ giả định xuyên suốt để minh họa cả 4 bước: Dự án xây dựng website giới thiệu dịch vụ và tiếp nhận khách hàng tiềm năng cho một doanh nghiệp.

10. Bước 1 — Thu thập và phân tích yêu cầu

Một sai lầm rất phổ biến là nghe khách hàng nói gì thì lập tức biến nó thành đầu việc kỹ thuật ngay. Khách nói muốn giao diện đẹp, đội ngũ nhảy vào vẽ. Khách nói muốn nhiều khách hàng tiềm năng, đội ngũ vội vàng đề xuất chạy ads.

Nhưng nếu chưa làm rõ mục tiêu thực sự đằng sau yêu cầu đó, chúng ta rất dễ giải quyết phần ngọn thay vì giải quyết đúng bài toán cốt lõi.

Các phương pháp thu thập yêu cầu hiệu quả

Với dự án website, thay vì chỉ hỏi “Anh thích website màu gì?”, tôi sẽ ưu tiên đào sâu vào 4 nhóm câu hỏi chiến lược:

• Nhóm 1: Về mục tiêu kinh doanh — Website mới giải quyết vấn đề gì mà website cũ không làm được? Hành động chuyển đổi mong muốn nhất của khách truy cập là gì (điền form, gọi hotline hay mua hàng)? Thước đo thành công của dự án sau 3 tháng bàn giao là gì?
• Nhóm 2: Về phạm vi sản phẩm — Website gồm chính xác những trang nào? Tính năng nào bắt buộc phải có ở ngày đầu ra mắt (Must-have), tính năng nào có thể bổ sung sau (Nice-to-have)? Có yêu cầu đặc biệt về ngôn ngữ, công nghệ hay chuẩn tương thích thiết bị không?
• Nhóm 3: Về trách nhiệm và nguồn lực — Ai sẽ chịu trách nhiệm cung cấp nội dung bài viết và hình ảnh bản quyền? Ai là đầu mối duy nhất có quyền duyệt giao diện cuối cùng? Khi có ý kiến trái chiều giữa các bên, ai sẽ đưa ra quyết định chốt?
• Nhóm 4: Về điều kiện bàn giao — Thời hạn bắt buộc đưa website vào hoạt động là ngày nào? Những tiêu chí kỹ thuật nào cần được kiểm tra trước khi ký biên bản nghiệm thu? Sau bàn giao, đơn vị thực hiện cần hỗ trợ bảo hành trong thời gian bao lâu và phạm vi như thế nào?

Sáu lỗi thường gặp khi thu thập yêu cầu (6 Traps)

Giáo trình SEONGON Academy chỉ ra 6 cái bẫy kinh điển khiến dự án trật bánh ngay từ vạch xuất phát:

1. Lỗi 1: Tự suy đoán thay vì hỏi lại (Assumption Trap): Khách hàng nói “Giao diện phải thật sang trọng”, designer tự hiểu là tone màu đen vàng ánh kim, nhưng khách hàng thực ra lại thích phong cách tối giản màu trắng xám Scandinavian.
2. Lỗi 2: Nghe yêu cầu nhưng quên hỏi mục tiêu (Feature vs Goal): Khách muốn tích hợp chatbot AI, nhưng hỏi ra mới biết mục đích chỉ là trả lời giờ mở cửa và địa chỉ — những thứ có thể giải quyết nhanh chóng bằng một bảng thông tin rõ ràng ở chân trang.
3. Lỗi 3: Ghi nhận yêu cầu quá mơ hồ: Ghi “Giao hàng sớm”, “Website chạy mượt” vào biên bản. Những từ ngữ này không thể đo lường và sẽ trở thành nguồn gốc tranh chấp khi nghiệm thu.
4. Lỗi 4: Chỉ trao đổi miệng qua điện thoại hoặc tin nhắn lẻ tẻ: Không có biên bản tổng hợp, dẫn đến tình trạng “tam sao thất bản”, người nhớ 15 bài viết, người cho rằng là 20 bài.
5. Lỗi 5: Không gửi xác nhận lại (Lack of Confirmation): Sau cuộc họp, hai bên nghĩ rằng mình đã hiểu nhau, nhưng trên thực tế mỗi người đang hình dung về một sản phẩm hoàn toàn khác.
6. Lỗi 6: Bỏ qua yêu cầu ngầm định (Implied Requirements): Ví dụ: khách hàng mặc định rằng website doanh nghiệp phải tương thích tốt với iPhone màn hình nhỏ, nhưng brief không ghi và đội ngũ cũng không kiểm thử trên môi trường đó.

Nguyên tắc thực hành: Mọi yêu cầu sau khi thu thập phải được viết lại thành văn bản (Meeting Minutes / Requirement Document) và gửi cho người có thẩm quyền phê duyệt ký xác nhận trước khi bắt tay làm bước tiếp theo.

11. Bước 2 — Viết Scope Statement: Thống nhất chính xác dự án sẽ làm đến đâu

Sau khi đã phân tích yêu cầu, bước tiếp theo là lập Scope Statement — Bản mô tả phạm vi dự án. Đây là văn bản pháp lý và chuyên môn quan trọng nhất để “khoanh vùng” dự án, giúp hai bên có chung một tiếng nói và bảo vệ đội ngũ khỏi bẫy Scope Creep.

Một bản Scope Statement tiêu chuẩn gồm 4 trụ cột:

1. Project Objectives (Mục tiêu dự án): Dự án làm ra để giải quyết bài toán gì, hoàn thành khi nào và trong điều kiện nào.
2. In-Scope (Phạm vi thực hiện): Danh sách chi tiết những hạng mục, tính năng và công việc dự án CAM KẾT thực hiện.
3. Out-of-Scope (Phạm vi loại trừ): Danh sách rõ ràng những hạng mục dự án KHÔNG THỰC HIỆN.
4. Acceptance Criteria (Tiêu chí nghiệm thu): Các điều kiện cụ thể, đo lường được để hai bên ký biên bản bàn giao.

Trong đó, phần Out-of-Scope có giá trị cực kỳ lớn. Rất nhiều bản kế hoạch chỉ ghi những gì sẽ làm mà ngại nói về những gì không làm. Chính khoảng trống mập mờ này là nơi nảy sinh mọi bất đồng khi dự án đi vào giai đoạn cuối.

Ví dụ Scope Statement hoàn chỉnh cho Dự án Website Doanh nghiệp

(Các mốc thời gian và thông số giả định phục vụ mục đích minh họa phương pháp)

Vì sao cần tiêu chí nghiệm thu có thể đo lường?

Hãy so sánh hai cách viết tiêu chí nghiệm thu sau đây để thấy sự khác biệt giữa một PM nghiệp dư và một PM chuyên nghiệp:

12. Bước 3 — WBS: Biến phạm vi lớn thành những phần việc có thể quản lý

Khi đã có Scope Statement, câu hỏi tiếp theo là: Làm sao để đảm bảo đội ngũ không bỏ sót bất kỳ hạng mục nào trong quá trình thực hiện?

Câu trả lời là Work Breakdown Structure (WBS) — Sơ đồ phân rã công việc. WBS là phương pháp chia nhỏ toàn bộ phạm vi dự án thành các khối công việc nhỏ hơn, có cấu trúc thứ bậc rõ ràng và hướng đến kết quả đầu ra.

Một WBS chuẩn mực nên hướng đến kết quả đầu ra (Deliverable-Oriented)

Thay vì đặt tên nhánh theo động từ hành động mơ hồ, hãy đặt tên theo danh từ thể hiện kết quả hoàn thành:

• Thay vì đặt: “Thiết kế website” → Đặt là: “Bộ thiết kế UI/UX được phê duyệt”.
• Thay vì đặt: “Viết bài” → Đặt là: “Bộ nội dung 5 trang bài viết hoàn chỉnh”.
• Thay vì đặt: “Test web” → Đặt là: “Hồ sơ kết quả kiểm thử và biên bản sửa lỗi”.

Bảng phân rã WBS 3 cấp mẫu cho Dự án Website Doanh nghiệp

Dưới đây là cấu trúc WBS phân rã theo 3 cấp độ: Cấp 1 (Dự án tổng thể) → Cấp 2 (Nhóm kết quả đầu ra chính) → Cấp 3 (Các gói công việc - Work Packages).

Phân biệt WBS, Task List và Timeline (Lịch trình)

Nhiều người mới làm quản lý thường nhầm lẫn giữa ba công cụ này:

Mối quan hệ: WBS tạo ra cấu trúc khung. Sau khi WBS rõ ràng, PM mới lấy các gói công việc ở cấp thấp nhất để rã ra Task List, rồi mới gán người thực hiện và xếp lên Timeline (Gantt Chart). Nếu chưa có WBS mà đã vội xếp Timeline, bạn chắc chắn sẽ bỏ sót các hạng mục quan trọng.

Work Package là gì và Quy tắc 8/80

Trong WBS, Work Package (Gói công việc) là hạng mục nằm ở cấp thấp nhất của mỗi nhánh phân rã. Đây là cấp độ đủ nhỏ để một cá nhân hoặc nhóm nhỏ có thể ước lượng chính xác về mặt thời gian, chi phí và nguồn lực.

Giáo trình SEONGON Academy đưa ra quy tắc thực nghiệm 8/80 để kiểm tra độ sâu của một Work Package:

• Không nên lớn hơn 80 giờ (khoảng 2 tuần làm việc): Nếu một gói công việc ước tính mất hơn 80 giờ, nó quá lớn và tiềm ẩn nhiều rủi ro không thể kiểm soát. Cần tiếp tục chia nhỏ hơn nữa.
• Không nên nhỏ hơn 8 giờ (1 ngày làm việc): Nếu chia nhỏ đến mức những việc mất 1–2 giờ (như 'gửi email', 'gọi điện thoại') cũng thành 1 nhánh WBS, hệ thống quản lý sẽ bị quá tải vì vi mô (Micro-management) không cần thiết.

13. Checklist: Làm sao biết WBS đã đủ tốt?

Trước khi ký duyệt WBS để đưa vào lập tiến độ, hãy tự đặt ra 5 câu hỏi thẩm định sau:

14. Bước 4 — Theo dõi và kiểm soát Scope khi dự án thay đổi

Ngay cả khi bạn đã có một bản Scope Statement hoàn hảo và một sơ đồ WBS mẫu mực, dự án vẫn sẽ xuất hiện những yêu cầu mới trong quá trình thực thi. Điều này là hoàn toàn bình thường trong kinh doanh.

Vấn đề của quản trị dự án không phải là dựng hàng rào cứng nhắc từ chối mọi yêu cầu, mà là: Bảo đảm mỗi thay đổi đều được thẩm định tác động và phê duyệt trước khi bắt tay thực hiện.

Quy trình 6 bước xử lý yêu cầu thay đổi (Change Control Procedure)

Tình huống thực tế: Khách hàng muốn bổ sung Chatbot AI giữa dự án

Giả sử website đang ở tuần thứ 5 (đang lập trình). Khách hàng bất ngờ nhắn tin: “Em ơi, sếp anh mới đi họp về, thích cái chatbot AI tự động tư vấn trên web đối thủ quá. Đội em tích hợp thêm cho anh con bot này vào website luôn nhé!”

Cách xử lý sai của PM non kinh nghiệm:

Cách xử lý chuyên nghiệp theo quy trình 6 bước:

Khi được phân tích rõ ràng, 90% khách hàng sẽ chọn phương án triển khai theo giai đoạn (Phase 2). Đây chính là sức mạnh của việc quản lý thay đổi: bảo vệ dự án bằng phương pháp luận thay vì sự đối đầu cảm tính.

15. Tổng hợp thực hành: Trước khi bắt đầu một dự án, cần có những gì?

Sau khi đi qua các khái niệm, điều đọng lại giá trị nhất không phải là việc ghi nhớ thật nhiều thuật ngữ tiếng Anh, mà là biết chính xác mình cần chuẩn bị những gì trước khi bấm nút khởi động dự án.

Tôi đúc kết thành bảng kiểm tra 8 câu hỏi sẵn sàng (Pre-launch Readiness Checklist):

Bài tập ứng dụng cho bạn

Để biến kiến thức thành phản xạ, hãy thử chọn một dự án bạn đang hoặc sắp làm (một chiến dịch truyền thông, một sự kiện workshop, làm website hoặc ra mắt sản phẩm):

• Bài tập 1: Viết Scope Statement trên 1 trang A4. Ghi rõ: Mục tiêu, In-Scope (gạch đầu dòng cụ thể), Out-of-Scope (ít nhất 4 điều không làm) và 3 tiêu chí nghiệm thu không thể cãi được.
• Bài tập 2: Lập sơ đồ WBS 3 cấp. Phân rã dự án thành ít nhất 4 nhóm kết quả đầu ra chính (Level 2). Dưới mỗi nhóm, rã tiếp thành các gói công việc cụ thể (Level 3) tuân thủ quy tắc 8/80 và đặt tên theo danh từ.

16. Một góc nhìn khác: Quản trị dự án cũng là một năng lực phát triển sự nghiệp

Buổi học còn giới thiệu lộ trình thăng tiến nghề nghiệp trong lĩnh vực Project Management, từ những vị trí điều phối ban đầu đến những vai trò chiến lược bao quát toàn tổ chức:

Điều này khiến tôi nhận ra một sự thật: Quản trị dự án không phải là kỹ năng độc quyền của những ai mang danh thiếp 'Project Manager'.

Dù bạn là một Marketer, Content Creator, UI/UX Designer, Lập trình viên hay Chuyên viên E-commerce, bạn đều sẽ được hưởng lợi cực lớn từ tư duy quản trị dự án:

• Một Marketer phụ trách chiến dịch cần biết cách khoanh vùng phạm vi (Scope) và phân bổ ngân sách chặt chẽ.
• Một Content Lead cần biết cách tổ chức WBS các bài viết, ấn phẩm để phối hợp nhịp nhàng với đội Design và Media.
• Một người làm Website/Tech cần thống nhất tiêu chí nghiệm thu cụ thể để tránh cảnh sửa đi sửa lại vô tận.

Khi công việc hiện đại ngày càng phức tạp và đòi hỏi sự phối hợp đa chức năng (Cross-functional collaboration), năng lực tổ chức, thiết lập ranh giới và dẫn dắt công việc về đích đúng hẹn chính là đòn bẩy lớn nhất giúp bạn tạo ra sự khác biệt trong sự nghiệp.

KẾT LUẬN — ĐỪNG BẮT ĐẦU DỰ ÁN CHỈ BẰNG MỘT DANH SÁCH CÔNG VIỆC

Sau khi hệ thống lại toàn bộ kiến thức của Buổi 1, tôi đúc kết được ba bài học nền tảng quan trọng nhất:

1. Dự án cần được quản lý như một hệ thống hoàn chỉnh: Mục tiêu, Phạm vi, Thời gian, Chi phí và Chất lượng liên kết hữu cơ với nhau trong Tam giác ràng buộc. Không thể tùy tiện siết một yếu tố mà hy vọng các yếu tố khác không bị ảnh hưởng.
2. Xác định phạm vi là việc quan trọng nhất trước khi triển khai: Một bản Scope Statement sắc nét với ranh giới In-Scope và Out-of-Scope rõ ràng sẽ giúp bảo vệ đội ngũ khỏi mọi tranh chấp và kiệt sức.
3. WBS là chiếc cầu nối giữa ý tưởng và hành động: WBS biến một mục tiêu to lớn thành những gói kết quả cụ thể, tạo tiền đề vững chắc cho việc ước lượng thời gian, giao việc và kiểm soát tiến độ.

Quản trị dự án bài bản không thể đảm bảo 100% mọi rủi ro sẽ biến mất. Nhưng nó mang lại cho chúng ta sự chủ động, giúp ta nhận diện vấn đề từ sớm, ra quyết định dựa trên dữ liệu và dẫn dắt đội ngũ về đích với sự tự tin cao nhất.