Trong thực tế ở các ngân hàng Việt Nam, phần lớn dự án nội bộ không do một người có chức danh "Project Manager" dẫn dắt. Người chịu trách nhiệm thường là trưởng phòng nghiệp vụ, chuyên viên cao cấp, hay một kỹ sư được tin tưởng giao việc. Họ không có quyền điều phối nhân sự từ phòng khác, không kiểm soát được ngân sách, nhưng vẫn phải chịu trách nhiệm khi dự án trễ hay thất bại.
Cuốn sách Project Management for Unofficial Project Managers của Kory Kogon, Suzette Blakemore và James Wood ra đời để giúp đúng nhóm người này — những người "vô tình trở thành PM" mà không được trang bị công cụ phù hợp.
Quản lý dự án không đòi hỏi chứng chỉ hay chức danh. Nó đòi hỏi sự rõ ràng, kỷ luật giao tiếp và khả năng xây dựng niềm tin — ba thứ ai cũng có thể học được.
Bộ tài liệu này trình bày lý thuyết từ cuốn sách, xen kẽ với câu chuyện hư cấu về một dự án có thật ở Ngân hàng B — để bạn thấy mỗi khái niệm hiện ra như thế nào trong thực tế.
Tháng 10 năm 2024. Ban lãnh đạo Ngân hàng B nhận ra rằng đội tài chính đang mất trung bình năm ngày mỗi tháng chỉ để tổng hợp số liệu báo cáo bằng tay trong Excel. Mỗi lần ngân hàng mẹ yêu cầu số liệu gấp, cả phòng lại rơi vào hỗn loạn. Quyết định được đưa ra: cần một hệ thống báo cáo tự động.
Người được giao dẫn dắt dự án này là Lan — trưởng phòng Kế hoạch Tài chính, người hiểu rõ yêu cầu nghiệp vụ nhất. Nhưng Lan chưa bao giờ quản lý một dự án công nghệ trước đây.
Dự án kéo dài ba tháng, từ tháng 11/2024 đến hết tháng 1/2025. Ngân sách 450 triệu đồng. Deadline cứng: phải đi vào vận hành trước khi chốt số liệu quý I năm 2025.
Hầu hết người quản lý dự án không chính thức đều bắt đầu từ bước lập kế hoạch — tức là bỏ qua bước đầu tiên và quan trọng nhất. Cuốn sách chỉ ra rằng có bốn giai đoạn cần đi qua theo thứ tự, và việc bỏ sót bất kỳ giai đoạn nào cũng đều gây ra vấn đề sau này.
Nguyên tắc quan trọng: Đừng bao giờ nhảy thẳng vào lập kế hoạch khi chưa xác định xong phạm vi. Cái bẫy phổ biến nhất là nhóm bắt tay làm việc ngay, rồi nửa đường mới phát hiện mọi người đang hiểu dự án theo những hướng hoàn toàn khác nhau.
Lan tổ chức họp khởi động với đủ mặt sáu người. Không khí hào hứng. Tổng Giám đốc Minh phát biểu mở đầu: "Chúng ta cần hệ thống báo cáo hiện đại, tự động hóa, dễ dùng." Mọi người gật đầu. Ai cũng nghĩ mình hiểu.
Sau cuộc họp, Hùng bắt tay viết code cho một giao diện cho phép người dùng tự kéo thả tạo báo cáo theo ý muốn. Đào bắt đầu thiết kế cơ sở dữ liệu cho chức năng phân tích nâng cao. Trong khi đó, Phương — người sẽ dùng hệ thống này hàng ngày — cứ nghĩ dự án chỉ đơn giản là tự động chạy đúng 12 báo cáo cố định mà phòng cô đang làm tay mỗi tháng.
Cuối tuần 2, Lan phát hiện Hùng đã dành ba ngày xây tính năng "tự tạo báo cáo linh hoạt" — một thứ không ai trong nhóm đồng ý làm, nhưng cũng không ai nói rõ là không làm. Đào đang thiết kế hệ thống phức tạp gấp đôi so với nhu cầu thực tế của Phương. Ba ngày công sức sắp trở thành rác.
Lan nhận ra mình đã mắc đúng cái lỗi mà nhiều người mới quản lý dự án hay mắc: bắt đầu làm trước khi thống nhất được "làm cái gì". Cô dừng tất cả lại và triệu tập một cuộc họp chỉ với một mục đích duy nhất: viết ra phạm vi dự án.
Bài học từ tình huống này: Sự hào hứng ban đầu không thay thế được sự rõ ràng. Hai ngày đầu tiên dành để viết ra chính xác dự án làm gì và không làm gì sẽ tiết kiệm được hai tuần sửa chữa sau đó.
Tài liệu xác định dự án không phải văn bản hành chính phức tạp. Nó trả lời năm câu hỏi cốt lõi mà bất kỳ ai trong nhóm cũng phải có cùng câu trả lời. Quan trọng hơn, nó được viết ra, được ký bởi người có quyền quyết định, và được dùng làm căn cứ mỗi khi có tranh cãi về việc "chúng ta có cần làm điều này không?"
| Câu hỏi | Ý nghĩa | Câu trả lời của Ngân hàng B |
|---|---|---|
| Tại sao dự án này tồn tại? | Vấn đề kinh doanh cần giải quyết | Tự động hóa 12 báo cáo quản trị tháng đang làm tay, rút ngắn thời gian chốt từ 5 ngày xuống còn 1 ngày |
| Kết quả bàn giao là gì? | Cụ thể hóa "done" trông như thế nào | 12 báo cáo chạy tự động theo lịch, hướng dẫn sử dụng, một buổi đào tạo cho phòng Tài chính, xác nhận nghiệm thu từ Giám đốc Tài chính |
| Không làm gì? | Ranh giới rõ ràng để tránh phình dự án | Không xây tính năng tự tạo báo cáo tùy ý, không tích hợp với hệ thống GL phiên bản mới của ngân hàng mẹ, không có ứng dụng di động |
| Thành công trông như thế nào? | Tiêu chí đo lường khách quan | Toàn bộ 12 báo cáo chạy đúng lịch trong 3 tháng liên tiếp, không cần can thiệp thủ công, được Giám đốc Tài chính ký nghiệm thu |
| Giới hạn là gì? | Ràng buộc cần ghi nhận từ đầu | Go-live trước 31/1/2025, ngân sách 450 triệu đồng, Hùng và Đào chỉ có thể dành 60% thời gian vì còn việc khác |
Vì sao cần chữ ký? Vì khi ai đó nói "Tôi nghĩ chúng ta cũng nên làm thêm tính năng X" vào tuần 7, bạn có thể mở tài liệu này ra và nói: "Chúng ta đã thống nhất từ đầu rằng X không thuộc phạm vi dự án này. Nếu muốn thêm, chúng ta cần thảo luận lại về thời gian và ngân sách." Điều đó không thể làm được nếu mọi thứ chỉ là thỏa thuận miệng.
Lan dành nửa ngày chuẩn bị một bản nháp trả lời năm câu hỏi cốt lõi, rồi triệu tập cuộc họp hai giờ. Lần đầu tiên, cả nhóm phải trả lời thành tiếng: "Dự án này để làm gì? Làm xong trông như thế nào? Điều gì chúng ta sẽ không làm?"
Phát hiện quan trọng nhất của cuộc họp: Hùng và Đào đều hiểu "hệ thống báo cáo hiện đại" có nghĩa là xây công cụ phân tích linh hoạt. Phương thì chỉ cần đúng 12 báo cáo cố định chạy tự động. Hai cách hiểu này nếu không được làm rõ sẽ dẫn đến hai hệ thống hoàn toàn khác nhau.
Tổng Giám đốc Minh tham gia 30 phút cuối cuộc họp. Lan đặt câu hỏi thẳng: "Anh ưu tiên giao nhanh 12 báo cáo cố định, hay ưu tiên một nền tảng linh hoạt hơn nhưng cần thêm 6 tuần?" Ông Minh không do dự: "Giao nhanh. Báo cáo cố định trước. Tính năng linh hoạt tính sau." Câu này được ghi vào tài liệu, ông ký tên.
Ba ngày sau, Hùng xin bổ sung thêm tính năng lọc dữ liệu nâng cao vào phạm vi dự án vì anh nghĩ "sẽ rất hữu ích". Lan mở tài liệu xác định ra, chỉ vào phần "không làm gì" và nói: "Anh Hùng, chúng ta đã thống nhất điều này rồi. Nếu sau khi go-live anh vẫn thấy cần, chúng ta lên kế hoạch cho Phase 2." Hùng gật đầu — không vui lắm, nhưng không có gì để tranh luận.
Chỉ trong tuần đầu tiên, tài liệu xác định dự án đã cứu nhóm khỏi một lần phình phạm vi. Đây không phải may mắn — đây là thiết kế. Tài liệu này tồn tại chính để làm việc đó.
Sai lầm điển hình: nhiều người chỉ nghĩ đến "khách hàng" (người dùng cuối) và "sếp" (người phê duyệt) khi lập danh sách các bên liên quan. Họ bỏ qua những người không trực tiếp dùng sản phẩm nhưng lại có quyền dừng dự án lại bất cứ lúc nào.
Cuốn sách phân loại các bên liên quan theo hai trục: mức độ ảnh hưởng (họ có quyền ra quyết định không?) và mức độ quan tâm (họ có theo dõi dự án không?). Từ đó có bốn nhóm với cách xử lý khác nhau.
Tại các tổ chức tài chính ở Việt Nam, bộ phận kiểm soát tuân thủ và đội công nghệ thông tin của ngân hàng mẹ thường là những "bên liên quan ẩn" — họ không có mặt trong cuộc họp kickoff nhưng lại có thể yêu cầu dừng dự án để kiểm tra vào bất kỳ lúc nào. Phát hiện ra điều này vào tuần thứ 8 của dự án là một trong những tình huống tồi tệ nhất có thể xảy ra.
Ngày thứ hai của tuần thứ ba, Lan nhận được email từ Tú — người mà cô chưa bao giờ gặp mặt. Tú là đại diện bảo mật công nghệ từ ngân hàng mẹ Ngân hàng B, chịu trách nhiệm phê duyệt mọi hệ thống mới có kết nối với cơ sở dữ liệu lõi (core banking).
Nội dung email rất ngắn gọn, nhưng nghe rất nặng: "Tôi vừa nghe có một hệ thống mới đang được xây dựng có kết nối với dữ liệu core banking. Hệ thống này chưa qua quy trình đánh giá bảo mật của chúng tôi. Đề nghị tạm dừng phát triển cho đến khi hoàn tất đánh giá."
Nếu Lan tuân thủ yêu cầu tạm dừng, dự án có thể trễ ba đến bốn tuần — đủ để lỡ deadline 31/1. Nhưng nếu cô tiếp tục không có phê duyệt bảo mật, rủi ro pháp lý và vận hành còn lớn hơn nhiều.
Lan nhận ra sai lầm của mình: khi lập danh sách các bên liên quan từ đầu, cô chỉ nghĩ đến những người bên trong công ty con Ngân hàng B. Cô đã không hỏi: "Quy trình phê duyệt từ ngân hàng mẹ là gì? Ai cần được thông báo?"
Thay vì tranh luận qua email, Lan xin gặp trực tiếp Tú trong ngày hôm đó. Cô mang theo tài liệu xác định phạm vi dự án và kiến trúc kỹ thuật mà Hùng đã phác thảo. Sau một giờ họp, Tú xác nhận rủi ro bảo mật thực sự không lớn vì hệ thống chỉ đọc dữ liệu, không ghi. Quá trình đánh giá chỉ cần một tuần thay vì bốn tuần như Lan lo lắng. Từ đó, Tú trở thành một phần của nhóm — được thêm vào danh sách cập nhật hàng tuần.
Cuốn sách giới thiệu khái niệm phân rã công việc — tức là chia nhỏ các deliverable (kết quả bàn giao) thành các công việc cụ thể đến mức có thể ước tính được thời gian hoàn thành. Nguyên tắc đơn giản: nếu một hạng mục công việc mất hơn ba ngày, nó vẫn còn quá lớn và cần chia nhỏ hơn nữa.
Nguyên tắc thứ hai: mỗi công việc phải có đúng một người chịu trách nhiệm. "Cả nhóm cùng làm" trong thực tế có nghĩa là không ai làm. Không phải vì mọi người lười biếng — mà vì khi không có tên cụ thể, ai cũng có lý do chính đáng để nghĩ người khác đang lo phần đó.
Vấn đề về thời gian dự phòng: Khi ước tính thời gian, cuốn sách khuyến nghị cộng thêm ít nhất 20% vào tổng thời gian. Trong môi trường ngân hàng, con số này nên cao hơn vì còn có các vòng phê duyệt nội bộ, yêu cầu đánh giá tuân thủ, và khả năng thành viên nhóm bị điều sang xử lý sự cố vận hành bất ngờ — tất cả đều là những điều có thể dự đoán được nhưng khó biết chính xác khi nào xảy ra.
Chi tiết quan trọng: Lan phát hiện Hùng đang tham gia một dự án khác của phòng IT. Thay vì giả định anh có đủ thời gian, cô đặt lịch gặp trực tiếp với IT Manager và yêu cầu xác nhận bằng email rằng Hùng được dành 60% thời gian cho dự án này trong ba tháng. Đây là điều cô học được từ việc đọc cuốn sách: những điều "hiển nhiên" nhất thường là những điều ít được nói ra nhất — và gây ra vấn đề lớn nhất sau này.
Cuốn sách phân biệt rõ hai khái niệm mà nhiều người hay nhầm lẫn: rủi ro là điều chưa xảy ra nhưng có thể xảy ra và sẽ gây ảnh hưởng xấu nếu không có biện pháp phòng ngừa. Vấn đề là điều đang xảy ra ngay bây giờ và cần quyết định trong vòng 48 giờ. Cách quản lý hai loại này hoàn toàn khác nhau.
Với rủi ro, nhiệm vụ của người quản lý dự án là nhìn về phía trước và hỏi: "Điều gì có thể cản trở chúng ta?" Sau đó đánh giá từng rủi ro theo hai chiều: khả năng xảy ra và mức độ ảnh hưởng nếu xảy ra. Những rủi ro có cả hai chỉ số đều cao cần được theo dõi chặt nhất.
| Rủi ro trong dự án Ngân hàng B | Mức độ | Biện pháp phòng ngừa |
|---|---|---|
| Hùng bị rút sang xử lý sự cố vận hành, mất thời gian làm dự án | Trung bình | Thỏa thuận bằng email với IT Manager về tỷ lệ thời gian dành cho dự án. Có đường báo cáo lên TGĐ Minh nếu vi phạm. |
| Yêu cầu báo cáo từ phòng Tài chính thay đổi sau khi đã xây xong | Trung bình | Phương ký xác nhận danh sách 12 báo cáo và định nghĩa từng chỉ tiêu ngay từ đầu. Mọi thay đổi sau tuần 3 phải đi qua quy trình xem xét tác động. |
| Dữ liệu trong core banking thiếu nhất quán, ảnh hưởng đến độ chính xác báo cáo | Trung bình | Đào hoàn thành khảo sát dữ liệu trong tháng 11 trước khi bắt đầu xây báo cáo. Phát hiện vấn đề sớm hơn là khi đang kiểm thử. |
| Phòng bảo mật ngân hàng mẹ yêu cầu thêm thay đổi kỹ thuật sau khi đã xây xong | Cao | Tú được mời tham gia từ tuần 3. Kiến trúc kỹ thuật được phê duyệt trước khi viết code. Đây là bài học từ tuần 3 đã được áp dụng. |
| Deadline 31/1 bị phá vỡ vì nhiều rủi ro nhỏ cộng dồn | Cao | Kế hoạch đặt go-live ngày 27/1 — dự phòng bốn ngày trước deadline cứng. Không làm thêm tính năng mới kể từ tuần 8. |
Cuốn sách nhấn mạnh: phần lớn dự án thất bại không phải vì vấn đề kỹ thuật, mà vì các bên liên quan không được cập nhật đúng lúc và đúng cách. Người quản lý dự án không chính thức thường mắc một trong hai lỗi: hoặc không báo cáo đủ (vì sợ bị đánh giá là chậm trễ), hoặc báo cáo quá nhiều (những cuộc họp dài mà không ai muốn dự).
Thứ Hai đầu tuần 7, IT Manager gọi điện cho Lan: hệ thống thanh toán của Ngân hàng B gặp sự cố nghiêm trọng, cần Hùng hỗ trợ toàn thời gian trong tuần này. "Chỉ một tuần thôi, Lan ơi."
Lan tính toán nhanh: mất Hùng một tuần vào thời điểm này đồng nghĩa với việc đợt 1 sẽ trễ tám ngày, đẩy lùi kiểm thử vào giữa tháng Một — ngay sát deadline 31/1. Dự phòng bốn ngày của cô vừa biến mất.
Lan viết báo cáo tuần với tín hiệu màu đỏ lần đầu tiên. Cô không che giấu, không làm nhẹ vấn đề. Câu đầu tiên trong email gửi TGĐ Minh: "Dự án đang gặp rủi ro trễ deadline do mất nguồn lực kỹ thuật đột xuất. Tôi cần quyết định của anh trong hôm nay."
Cô đưa ra hai phương án kèm phân tích tác động: cho Hùng đi xử lý sự cố và chấp nhận trễ hai tuần, hoặc thuê thêm một developer tự do trong vòng một tuần để thay thế Hùng trong dự án báo cáo. Phương án 2 tốn thêm 15 triệu đồng nằm trong phần dự phòng ngân sách.
TGĐ Minh phản hồi trong hai giờ: chọn phương án 2 — thuê thêm developer tự do. Ông cũng nhân tiện gửi email xác nhận lại cam kết thời gian của Hùng với dự án sau khi sự cố được giải quyết. Dự án giữ nguyên được kế hoạch. Điều quan trọng hơn: ông Minh tin tưởng Lan hơn vì cô đã nói thẳng thay vì cố gắng tự xử lý một mình.
Cuốn sách không nói rằng bạn phải từ chối mọi thay đổi yêu cầu. Nó nói rằng mỗi thay đổi cần được xem xét một cách có ý thức, với đủ thông tin về tác động trước khi quyết định. Vấn đề không phải là "có thay đổi hay không" — vấn đề là ai quyết định, dựa trên thông tin gì.
Quy trình xử lý thay đổi yêu cầu có bốn bước:
Ngày 27/1, toàn bộ 12 báo cáo chạy lần đầu tiên trên môi trường thực tế. Đào kiểm tra từng chỉ tiêu. Hùng theo dõi log hệ thống. Phương ngồi cạnh nhìn số liệu hiện ra — đúng với những gì cô đã ký xác nhận từ tháng trước. Không có lỗi nghiêm trọng.
Nhưng Lan biết đây chưa phải là kết thúc. Cô có một checklist dài cho bốn ngày cuối cùng.
Lan tổ chức buổi họp 90 phút với cả nhóm vào ngày cuối cùng. Cô hỏi ba câu: điều gì hoạt động tốt (phát hiện ra Tú sớm sau khi sự cố tuần 3), điều gì không hoạt động tốt (khảo sát yêu cầu từ Phương mất lâu hơn dự kiến vì định nghĩa chỉ tiêu chưa rõ), và lần sau sẽ làm khác gì (dành thêm một tuần cho khảo sát yêu cầu trước khi lập kế hoạch). Tài liệu này được gửi cho IT Manager và lưu vào kho kinh nghiệm dự án của công ty.