Foundations of Project Management

Dự án phần mềm hay dự án kinh doanh hiếm khi thất bại vì team không biết viết code hay vì người làm lười. Phần lớn dự án trật đường ray là do phạm vi mơ hồ, các bên liên quan mỗi người kỳ vọng một kiểu, và rủi ro ngầm không ai phát hiện kịp. Vì vậy Quản lý Dự án (Project Management) là kỹ năng tổ chức nào cũng cần.

# Dự án và Quản lý Dự án là gì

Bắt đầu với nghề Quản lý Dự án, việc đầu tiên là phân biệt cho rõ Dự án (Project) với Vận hành hằng ngày (Operations):

Tiêu chí	Vận hành hằng ngày (Operations)	Dự án (Project)
Bản chất công việc	Lặp đi lặp lại theo quy trình chuẩn, chạy theo chu kỳ	Việc làm trong một thời gian nhất định để tạo ra sản phẩm, dịch vụ hay kết quả chưa từng có
Mục tiêu chính	Giữ việc kinh doanh chạy liên tục, ổn định, đúng SLA	Tạo ra cái mới, cải tiến, hoặc thay đổi cách tổ chức đang vận hành
Thời hạn	Chạy liên tục, không có ngày kết thúc định trước	Có ngày bắt đầu và ngày kết thúc (Deadline) rõ ràng, xong là giải tán
Cơ cấu tổ chức	Phòng ban cố định, chia theo chuyên môn	Team liên chức năng (Cross-functional) gom riêng cho dự án
Ngân sách	Chi phí hoạt động định kỳ hằng năm (OpEx)	Ngân sách cấp riêng cho dự án, thường (không phải luôn luôn) hạch toán là đầu tư (CapEx)
Thước đo thành công	Hiệu suất, độ ổn định hệ thống, đúng SLA, tối ưu chi phí	Bàn giao đúng Scope, đúng hạn (Time), đúng chi phí (Cost) và chất lượng
Ví dụ	Trực hệ thống 24/7, xử lý ticket hỗ trợ, bảo trì định kỳ	Làm cổng thanh toán mới, chuyển hệ thống lên Cloud

Dự án (Project) là một nỗ lực có thời hạn, làm ra để tạo một sản phẩm, dịch vụ hoặc kết quả độc nhất.

Quản lý Dự án (Project Management) là đem kiến thức, kỹ năng, công cụ và kỹ thuật áp vào các hoạt động của dự án, để đáp ứng (hoặc vượt) kỳ vọng của các bên liên quan (Stakeholders) trong khi nguồn lực thì có hạn.

# tam giác ràng buộc: quản lý sự đánh đổi (Trade-off Management)

Chẳng dự án nào có nguồn lực vô hạn. PM nào cũng phải làm việc trong khuôn khổ tam giác ràng buộc (The Triple Constraint):

Phạm vi (Scope): toàn bộ tính năng, yêu cầu kỹ thuật và đầu việc cần làm xong.
Thời gian (Time): lịch bàn giao, các mốc quan trọng (Milestones) và hạn chót (Deadline).
Chi phí và tài nguyên (Cost / Resources): ngân sách, công cụ phần mềm và số người tham gia.
Chất lượng (Quality): nằm ở giữa. Một trong ba đỉnh tam giác thay đổi mà không cân lại thì chất lượng sản phẩm lãnh đủ.

# ma trận đánh đổi (Trade-off Matrix)

Khi có biến động ngoài ý muốn (ví dụ đối thủ ra tính năng mới, dự án buộc phải ra mắt sớm hơn), PM không được hứa suông kiểu "bọn em làm nhanh hơn mà vẫn giữ nguyên mọi thứ". Họ dùng ma trận đánh đổi: chốt với các bên xem ràng buộc nào giữ cố định, ràng buộc nào được tối ưu hoặc co giãn, và ràng buộc nào chấp nhận để nó xấu đi:

Ràng buộc	Cố định (Fixed / Constrain)	Linh hoạt (Flexible / Optimize)	Chấp nhận (Accept)
Thời gian	CỐ ĐỊNH: Ngày ra mắt không xê dịch
Phạm vi		LINH HOẠT: Bớt mấy tính năng phụ
Chi phí			CHẤP NHẬN TĂNG: Thuê thêm chuyên gia tư vấn

# kiểm soát phình phạm vi (Scope Creep) và Gold Plating

Scope Creep (phình phạm vi) là khi yêu cầu, tính năng mới cứ lặng lẽ được nhét thêm vào dự án mà thời gian, ngân sách hay nhân sự không được điều chỉnh theo. Đây là một trong những thứ âm thầm giết dự án hay gặp nhất.

# phân biệt Scope Creep và Gold Plating

Scope Creep: đến từ bên ngoài (khách hàng, sếp nói thêm yêu cầu bằng miệng trong mấy buổi demo).
Gold Plating (mạ vàng sản phẩm): đến từ chính team kỹ thuật. Dev tự làm thêm tính năng phức tạp hoặc tối ưu quá đà (over-engineering) mà khách không hề yêu cầu và cũng chẳng đem lại giá trị kinh doanh nào.

# quy trình kiểm soát thay đổi (Change Control Process)

Ghi nhận yêu cầu chính thức: thay đổi nào cũng phải thành Change Request Ticket, không nhận yêu cầu miệng qua tin nhắn hay lúc gặp ngoài hành lang.
Đánh giá tác động (Impact Analysis): thay đổi này tốn bao nhiêu Story Points, lùi deadline bao nhiêu ngày, kéo theo rủi ro gì.
Thương lượng đánh đổi: "Nếu thêm thanh toán Apple Pay ngay sprint này thì mình phải dời tính năng xuất báo cáo PDF sang sprint sau".

# đo sức khoẻ dự án bằng Earned Value Management (EVM)

Ở dự án làm bài bản, chỉ hỏi "dự án xong bao nhiêu phần trăm rồi?" thì thường nhận về câu trả lời theo cảm tính (hội chứng 90%: dự án lên 90% rất nhanh, còn 10% cuối thì mất cả năm).

Earned Value Management (EVM) là phương pháp định lượng có chuẩn hẳn hoi (PMI đưa vào PMBOK, ở Mỹ có chuẩn EIA-748), quy cả tiến độ lẫn chi phí về cùng một đơn vị là tiền để so với nhau. Muốn số liệu đáng tin thì phần việc phải được chia nhỏ và có tiêu chí "xong" rõ ràng, không thì EV cũng lại là cảm tính:

# công thức tính độ lệch và hiệu suất

Độ lệch tiến độ (Schedule Variance): SV = EV - PV
- SV > 0: dự án đang nhanh hơn kế hoạch.
- SV < 0: dự án đang chậm tiến độ.
Độ lệch chi phí (Cost Variance): CV = EV - AC
- CV > 0: dự án đang tiết kiệm (dưới ngân sách).
- CV < 0: dự án đang vượt ngân sách (tiêu tiền nhanh hơn dự kiến).
Chỉ số hiệu suất tiến độ (Schedule Performance Index): SPI = EV / PV
- SPI = 1.0: đúng tiến độ.
- SPI < 1.0: phần việc làm xong ít hơn lượng việc lẽ ra phải xong tới thời điểm này (ví dụ SPI = 0.8 nghĩa là mới đạt 80% khối lượng theo kế hoạch).
Chỉ số hiệu suất chi phí (Cost Performance Index): CPI = EV / AC
- CPI < 1.0: dự án đang bội chi (ví dụ CPI = 0.85 nghĩa là chi $1.00 nhưng chỉ thu về lượng việc trị giá$ 0.85).

Ví dụ cho dễ hình dung: dự án có tổng ngân sách (BAC, Budget at Completion) là 1 tỷ. Tới cuối tháng 3, theo kế hoạch lẽ ra phải xong phần việc trị giá 400 triệu (PV = 400). Thực tế mới nghiệm thu được phần việc trị giá 320 triệu (EV = 320), trong khi đã tiêu 400 triệu (AC = 400). Tính ra SV = -80, CV = -80, SPI = 0.8, CPI = 0.8: vừa chậm vừa đắt. Nếu hiệu suất chi phí cứ giữ như vậy tới cuối, ước tính tổng chi phí khi xong (EAC) là BAC / CPI = 1 / 0.8 = 1.25 tỷ, tức vượt 250 triệu. Con số này có từ tháng 3, đủ sớm để còn kịp xoay xở.

Có một cạm bẫy nên biết: SV và SPI đo bằng tiền chứ không đo bằng ngày. Đến cuối dự án, mọi phần việc đều xong nên EV luôn bằng PV, SPI tự quay về 1.0 dù dự án có trễ ba tháng. Vì vậy ở giai đoạn cuối, SPI không còn nói lên gì; người ta bổ sung phương pháp Earned Schedule (đo độ trễ bằng đơn vị thời gian) hoặc nhìn thẳng vào đường găng.

# ma trận trách nhiệm RACI khi phối hợp liên phòng ban

Đầu việc hay bị tắc vì hai lý do: "cha chung không ai khóc", hoặc quá nhiều người cùng chỉ đạo. Khung RACI chia vai cho từng người thật rõ:

Tác vụ dự án	Technical Lead	Project Manager	Developer	QA Engineer	Product Owner
Thiết kế kiến trúc hệ thống	A / R	I	C	I	C
Lập kế hoạch Release & Sprint	C	A	C	C	R
Viết code tính năng	C	I	A / R	I	I
Kiểm thử chấp nhận người dùng (UAT)	I	C	I	R	A
Duyệt deploy lên Production	A	C	R	C	I

IMPORTANT

Nguyên tắc quan trọng nhất của RACI: mỗi tác vụ chỉ được có ĐÚNG MỘT chữ A (Accountable). Hai người cùng là Accountable thì sẽ giành quyền; không ai là Accountable thì có sự cố chẳng ai chịu trách nhiệm.

# bốn giai đoạn trong vòng đời dự án

Cách chia kinh điển của PMI (PMBOK Guide, ấn bản 6) có năm nhóm quy trình: Initiating, Planning, Executing, Monitoring & Controlling, Closing. Giám sát thật ra chạy song song suốt dự án chứ không phải một bước nằm sau thực thi, nên ở đây mình gộp nó với Executing cho gọn thành bốn giai đoạn.

# 1. khởi tạo (Initiating)

Mục tiêu là trả lời câu hỏi: Dự án này có đáng bỏ nguồn lực ra không?

Viết Project Charter: văn bản chính thức xác nhận dự án tồn tại, phạm vi tổng quát, ngân sách sơ bộ và chỉ định Project Manager.
Vẽ bản đồ các bên liên quan (Stakeholder Analysis): ai được hưởng lợi, ai là người duyệt, ai có thể gây rủi ro cho dự án.

# 2. lập kế hoạch (Planning)

Mục tiêu là có một lộ trình làm được thật:

Chia nhỏ công việc (Work Breakdown Structure - WBS): bẻ mục tiêu lớn thành các gói việc (Work Packages) đủ nhỏ để ước lượng thời gian và giao cho từng người.
Xác định đường găng (Critical Path Method - CPM): chuỗi tác vụ nối tiếp dài nhất, quyết định tổng thời gian của dự án. Trễ bất kỳ chỗ nào trên đường găng là trễ deadline của cả dự án.

# 3. thực thi và giám sát (Executing & Monitoring)

Giai đoạn ngốn nhiều thời gian và sức lực của team nhất:

Theo dõi tiến độ bằng công cụ trực quan (Kanban Board, Burn-down Chart).
Chủ động quản lý rủi ro bằng Ma trận RAID:

Thành phần RAID	Định nghĩa	PM cần làm gì
Risks (Rủi ro)	Chuyện chưa xảy ra, nhưng xảy ra thì gây hại	Đánh giá xác suất và mức ảnh hưởng, lên kế hoạch dự phòng (Mitigation Plan)
Assumptions (Giả định)	Điều kiện đang được coi là đúng nhưng chưa kiểm chứng	Chủ động hỏi các bên để xác nhận giả định càng sớm càng tốt
Issues (Vấn đề phát sinh)	Sự cố đã thật sự xảy ra	Phân loại mức nghiêm trọng, huy động người xử lý nhanh
Dependencies (Phụ thuộc)	Việc của team mình phải chờ kết quả của team khác	Chốt rõ thời hạn bàn giao (SLA) và theo dõi sát

# 4. đóng dự án (Closing)

Nghiệm thu sản phẩm chính thức với khách hàng hoặc ban điều hành.
Họp rút kinh nghiệm (Project Retrospective / Post-mortem): ghi lại bài học (Lessons Learned) để dự án sau không lặp lại lỗi cũ.
Trả lại nguồn lực và lưu tài liệu dự án vào kho kiến thức chung của công ty.

# chọn mô hình triển khai: Agile, Waterfall hay Hybrid?

Không có phương pháp quản lý nào hợp với mọi dự án. Quan trọng là chọn đúng mô hình cho đúng bối cảnh:

Tiêu chí	Waterfall (Thác nước)	Agile / Scrum	Hybrid (Lai ghép)
Yêu cầu	Cố định, rõ ràng ngay từ đầu	Hay thay đổi, chạy theo thị trường	Khung kiến trúc cố định, tính năng con linh hoạt
Lúc bàn giao	Một lần duy nhất ở cuối dự án	Bàn giao dần sau mỗi Sprint (≤ 1 tháng)	Theo từng Milestone lớn (3 tháng)
Chi phí thay đổi	Rất đắt nếu đổi ở giai đoạn cuối	Thấp, thay đổi là chuyện bình thường	Trung bình, kiểm soát qua Change Request
Dự án tiêu biểu	Chuyển Data Center vật lý, tuân thủ PCI-DSS	App di động, nền tảng SaaS, sản phẩm AI	Core Banking, chuyển đổi số ở doanh nghiệp lớn

# các vai trò nghề nghiệp trong Quản lý Dự án

Nghề Quản lý Dự án có nhiều hướng đi, tuỳ thế mạnh của mỗi người:

Project Coordinator: chỗ khởi đầu hợp lý, chủ yếu sắp lịch, chuẩn bị tài liệu họp, theo dõi các đầu việc nhỏ và hỗ trợ PM chính.
Project Manager (PM): chịu trách nhiệm trực tiếp chuyện thành bại của một dự án cụ thể, từ lúc lập kế hoạch tới khi bàn giao.
Technical Project Manager (TPM): thường đi lên từ kỹ sư phần mềm hoặc kỹ sư hệ thống. TPM vừa quản lý tiến độ, vừa tham gia đánh giá kiến trúc có khả thi không, rủi ro khi tích hợp các hệ thống phức tạp, và điều phối các dự án hạ tầng lớn.
Program Manager: quản lý một nhóm dự án gắn chặt với nhau (ví dụ chương trình chuyển đổi số của một ngân hàng gồm 10 dự án nhỏ). Việc chính là tối ưu lợi ích chung thay vì chỉ nhìn từng dự án riêng lẻ.
Portfolio Manager: làm việc sát với ban lãnh đạo (C-Suite) để chọn, xếp ưu tiên và rót vốn cho những dự án có giá trị chiến lược nhất, đồng thời dám khai tử những dự án không còn hiệu quả.

# checklist khởi động dự án mới

Trước khi bắt tay vào dự án nào, hãy chắc là bạn đã trả lời đủ 5 câu hỏi sau:

Thế nào là thành công: dự án xong và xong tốt nghĩa là gì, đo bằng chỉ số định lượng nào (KPIs / OKRs)?
Ranh giới phạm vi: tính năng nào bắt buộc phải có (Must-have), tính năng nào chắc chắn không làm ở giai đoạn này (Out of scope)?
Các bên liên quan chính: ai là người có quyền nghiệm thu cuối cùng (Product Owner / Project Sponsor)?
Phụ thuộc có thể gây nghẽn: dự án có cần team bên ngoài nào hỗ trợ không, họ đã cam kết lịch chưa?
Kế hoạch dự phòng: nếu trễ 2 tuần thì cắt bớt cái gì trước?

Muốn đọc sâu hơn thì có hai tài liệu gốc: PMBOK Guide của PMI cho cách làm truyền thống, và Scrum Guide (miễn phí ở scrumguides.org) cho Agile. Đọc xong, thử đem dự án đang làm ra tính EVM một lần, hoặc ngồi kẻ bảng RACI cho mấy đầu việc hay bị đá qua đá lại, sẽ thấy ngay chỗ nào đang hổng.

Chỉ là những ghi chép cá nhân với hy vọng mang lại chút giá trị. Nếu thấy hữu ích, đừng ngại chia sẻ cho bạn bè & đồng nghiệp nhé!

Happy coding 😎 👍🏻 🚀 🔥.