Trước khi bàn tới công cụ hay phương pháp luận, cần hiểu thật rõ những khái niệm gốc: dự án thực chất là gì, người quản lý dự án (Project Manager) chịu trách nhiệm những gì, các ràng buộc luôn kéo nhau, ai là stakeholder, dự án đi qua những nhóm quy trình nào và thế nào mới gọi là thành công. Đây là nền móng cho mọi bài sau.
Theo PMI, dự án (project) là một nỗ lực tạm thời được thực hiện để tạo ra một sản phẩm, dịch vụ hoặc kết quả duy nhất. Hai từ khóa định nghĩa nên bản chất của dự án:
Để không nhầm lẫn, hãy phân biệt dự án với những khái niệm hay đi kèm:
| Khái niệm | Đặc điểm | Ví dụ |
|---|---|---|
| Project (Dự án) | Nỗ lực tạm thời, có đầu–cuối, tạo ra kết quả duy nhất | Xây dựng và ra mắt ứng dụng đặt hàng mới |
| Operations (Vận hành) | Hoạt động lặp lại liên tục, không có điểm kết thúc; duy trì việc kinh doanh hằng ngày | Vận hành, bảo trì, hỗ trợ ứng dụng đó hằng ngày |
| Program (Chương trình) | Một nhóm các dự án liên quan được quản lý phối hợp để đạt lợi ích mà nếu quản lý riêng lẻ sẽ không có | Chương trình "Chuyển đổi số" gồm nhiều dự án: app, ERP, kho dữ liệu |
| Portfolio (Danh mục) | Tập hợp các dự án, chương trình và hoạt động được nhóm lại để quản lý theo mục tiêu chiến lược của tổ chức | Toàn bộ đầu tư công nghệ của công ty trong năm |
Project vs Product: dự án là quá trình (cách ta làm), còn sản phẩm (product) là kết quả tồn tại lâu dài sau khi dự án kết thúc. Một dự án có thể sinh ra một phần của sản phẩm; một sản phẩm có thể trải qua nhiều dự án trong vòng đời của nó (phát triển, nâng cấp, mở rộng). Dự án có ngày kết thúc; sản phẩm thì sống cùng vận hành cho tới khi bị khai tử.
Project Manager (PM) là người chịu trách nhiệm đưa dự án đi từ ý tưởng tới kết quả: đúng phạm vi, đúng hạn, đúng ngân sách và đạt chất lượng mong muốn. PM không trực tiếp làm hết mọi việc — PM điều phối để cả guồng máy vận hành trơn tru. Trách nhiệm chính gồm:
Mọi dự án bị giới hạn bởi ba ràng buộc cốt lõi tạo thành một tam giác — thường gọi là Iron Triangle (tam giác sắt) hay Triple Constraint:
Nằm ở giữa tam giác là Quality (Chất lượng) — chất lượng là hệ quả của việc cân bằng ba cạnh kia. Nguyên tắc quan trọng nhất: thay đổi một cạnh sẽ ảnh hưởng tới các cạnh còn lại. Bạn không thể siết một cạnh mà giữ nguyên hai cạnh kia.
| Tình huống | Hệ quả kéo theo |
|---|---|
| Thêm phạm vi (scope) nhưng giữ nguyên deadline | Phải tăng chi phí (thêm người) hoặc giảm chất lượng |
| Rút ngắn thời gian (deadline gấp) nhưng giữ nguyên phạm vi | Phải tăng chi phí hoặc chất lượng giảm |
| Cắt ngân sách (cost) nhưng giữ nguyên phạm vi và hạn | Chất lượng gần như chắc chắn giảm |
| Muốn chất lượng cao hơn với cùng phạm vi | Cần thêm thời gian hoặc thêm chi phí |
Stakeholder (bên liên quan) là bất kỳ cá nhân hay nhóm nào có thể ảnh hưởng tới dự án hoặc bị ảnh hưởng bởi dự án. Một số stakeholder điển hình:
| Stakeholder | Vai trò / mối quan tâm |
|---|---|
| Sponsor (Nhà tài trợ) | Người cấp ngân sách và quyền lực; bảo trợ cho dự án, gỡ vướng cấp cao |
| Khách hàng (Customer) | Người trả tiền hoặc đặt yêu cầu; quan tâm dự án có giải quyết được vấn đề của họ không |
| Team (Nhóm dự án) | Người trực tiếp thực hiện công việc; quan tâm yêu cầu rõ ràng và môi trường làm việc tốt |
| End-user (Người dùng cuối) | Người thực sự dùng sản phẩm; quan tâm tính dễ dùng và hữu ích |
| Quản lý / phòng ban | Quản lý cấp trên, các bộ phận liên quan (pháp chế, tài chính, vận hành...) |
Phân tích stakeholder giúp PM biết nên dồn sức giao tiếp với ai. Một công cụ phổ biến là Power/Interest Grid — chia stakeholder theo hai trục Quyền lực (power) và Mức độ quan tâm (interest):
| Quan tâm thấp | Quan tâm cao | |
|---|---|---|
| Quyền lực cao | Giữ hài lòng (Keep satisfied) | Quản lý sát sao (Manage closely) |
| Quyền lực thấp | Theo dõi (Monitor) | Cung cấp thông tin (Keep informed) |
Vì sao quản lý kỳ vọng stakeholder là sống còn? Vì thành công của dự án được đánh giá phần lớn qua cảm nhận của stakeholder. Một dự án đúng hạn, đúng ngân sách vẫn có thể bị coi là thất bại nếu stakeholder kỳ vọng một thứ khác với cái họ nhận được. Quản lý kỳ vọng từ sớm và liên tục giúp tránh bất ngờ, xung đột và việc làm lại tốn kém.
PMBOK chia công việc quản lý dự án thành 5 nhóm quy trình (Process Groups). Mỗi nhóm có mục đích và đầu ra (deliverable) đặc trưng:
| Nhóm quy trình | Làm gì | Deliverable chính |
|---|---|---|
| 1. Initiating (Khởi tạo) | Định nghĩa dự án ở mức cao, xác định mục tiêu và stakeholder, được cấp phép khởi động | Project Charter, danh sách stakeholder |
| 2. Planning (Lập kế hoạch) | Chi tiết hóa phạm vi, lịch trình, ngân sách, chất lượng, rủi ro, giao tiếp, nguồn lực | Project Management Plan, WBS, lịch, ngân sách |
| 3. Executing (Thực thi) | Tiến hành công việc theo kế hoạch, điều phối con người và nguồn lực để tạo ra sản phẩm | Các sản phẩm bàn giao (deliverables) |
| 4. Monitoring & Controlling (Giám sát & Kiểm soát) | Theo dõi tiến độ, đo lường, so sánh với kế hoạch, kiểm soát thay đổi, xử lý lệch hướng | Báo cáo tiến độ, yêu cầu thay đổi, cập nhật kế hoạch |
| 5. Closing (Đóng dự án) | Nghiệm thu, bàn giao chính thức, đóng hợp đồng, rút bài học kinh nghiệm | Bàn giao cuối, tài liệu lessons learned, đóng dự án |
Quan niệm cổ điển coi dự án thành công khi đạt cả ba cạnh của tam giác ràng buộc, nhưng một định nghĩa đầy đủ hơn bao gồm nhiều yếu tố:
Phân biệt "project success" và "product success":
| Loại | Đo cái gì | Ví dụ |
|---|---|---|
| Project success | Dự án được thực thi tốt: đúng phạm vi, hạn, ngân sách, chất lượng, stakeholder hài lòng | App được giao đúng hạn, trong ngân sách, đúng yêu cầu |
| Product success | Đầu ra tạo ra giá trị sau đó: người dùng dùng nhiều, doanh thu tăng, đạt mục tiêu kinh doanh | App đó về sau được hàng triệu người dùng, sinh lợi nhuận |
Một dự án có thể thành công về mặt thực thi (project success) nhưng sản phẩm vẫn thất bại trên thị trường (product fail) — và ngược lại. PM cần ý thức cả hai góc nhìn này.