Quản lý rủi ro dự án

 

Chả hiểu sao rất nhiều người đã không hình dung về rủi ro, lại còn không thể phân biệt được quản lý rủi ro thông thường và quản lý rủi ro dự án.

Quản lý rủi ro dự án sẽ liên quan đến những tình huống bất trắc có thể xảy ra và làm ảnh hưởng đến tiến độ, chất lượng dự án nói chung hoặc ảnh hưởng đến mục tiêu, kết quả (outcomes) chung của dự án. Vì thế, nếu nó không xảy ra thì thôi; mà nếu xảy ra, tôi hiểu nó (risks) có thể ảnh hưởng outcome. 

Vậy thì các dạng rủi ro dự án tổng quan là:

• Chi phí: Một số tình huống bất trắc có thể dẫn đến tăng chi phí phát sinh (nhất là mấy dự án cầu đường liên quan giải phóng mặt bằng...). Cũng có thể do ước lượng công việc cụ thể chưa hoàn chỉnh. VD bản quyền các phần mềm có liên quan khi thuê 1 phần mềm. 

• Lịch trình: Một số sự kiện xảy ra khiến dự án bị hoãn. Tuy nhiên cần phân biệt tác động trễ tiến độ và 1 nguy cơ rủi ro gây nên việc trễ tiến độ. VD: 

• RR tay Engineer duy nhất của PRJ nghỉ phép, gây ảnh hưởng đến tiến độ dự án tại bước XYZ => Risk mitigation: cử 1 full-time engineer và 1 part-time engineer cho dự án hơn là chỉ 1 full-time engineer. 

• 1 sự cố ATTT xảy ra dẫn đến phase data import phải ngưng trệ, và cần phải đánh giá integrity trước khi tiếp tục thực hiện import. => Bổ sung task backup sẵn data cần import, thực hiện trước khi import.

• Sự cố lockdown do Corona virus, dẫn đến không thể làm việc tại VP mà phải làm việc WFH (dạng RR thảm hoạ thiên nhiên). 

• Những RR khác như lỗi phần cứng trong quá trình thực hiện Prj, rủi ro do sai sót bởi con người...

• Hiệu suất (Performance): Kết quả dự án không đạt như mục tiêu mong đợi hoặc đặc điểm kỹ thuật (specifications) của dự án. 

Vậy công thức chung của 1 risk sẽ là: 

Do X, Y có thể xảy ra, gây ra tác động Z. 

Xác định risks, theo mình, tốt là là xác định trong từng bước, từng công việc của dự án.

Đồng thời, cũng cần thực hiện 1 phương pháp//quy trình quản lý rủi ro dự án hoàn chỉnh. Steps:

• Identify Risk theo công thức trên
• Assign Ownership
• Analyze//Assess và sau đó Prioritize
• Respond
• Monitor

Những gì mình viết ở trên chủ yếu tham khảo từ https://www.northeastern.edu/graduate/blog/project-risk-management/. 

Và đây chỉ là đề xuất 1 PP Quản lý rủi ro dự án. Trên Internet cũng có thể có những PP quản lý khác, VD căn cứ theo DS Risks nói chung https://www.stakeholdermap.com/risk/register-common-project-risks.html. 

Hình minh hoạ nêu một số risks có thể xảy ra nói chung. Chưa hẳn là risks ứng với mỗi bước công việc của dự án nhưng đủ để chúng ta hình dung risks cần xác định là gì và bằng cách nào. Nguồn: https://www.liamwho.com/risk-management-w03/ 

Cheers!

Redmine 101

Một dạng dashboard của RedmineCRM, mô tả khối lượng công việc của từng cá nhân nhóm theo trạng thái.
Nguồn: RedmineCRM

Xuất phát từ nhu cầu sử dụng 1 hệ thống mã mở, linh hoạt trong việc quản lý dự án, đồng thời cũng vì phải có 1 nơi lưu trữ quản lý các thay đổi đ/v hệ thống CNTT nói chung (do cty kiểm toán yêu cầu), chúng tôi tìm đến trac[1] trước tiên (chứ ko phải là Redmine[2]). trac về cơ bản khá tốt, đặc biệt phần quản lý tickets/issues, lại được viết bằng python, là ngôn ngữ lập trình mà cá nhân tôi rất thích. Nhưng trac cũng có cái dở, tồn tại 1 số vấn đề tương đối nghiêm trọng: đa số các chức năng quản trị chỉ được hỗ trợ thông qua dòng lệnh và còn tạo mỗi dự án 1 database riêng[3]... Các vấn đề này khiến cho việc quản trị trac khá vất vả. Vì thế sau khi dùng khoảng 2 năm, đến 2010, chúng tôi quyết định tìm phần mềm mới thay thế trac. Và Redmine sau bao nhiêu năm sử dụng, đã không phụ lòng mong mỏi của chúng tôi.

Công việc chuyển dữ liệu từ trac sang Redmine không quá khó khăn (dễ đến nỗi anh chàng phụ trách việc này ko kịp viết lại tài liệu :D). Kế đến, tất cả các chức năng quản trị như quản lý người dùng, nhóm, phân quyền, quản lý dự án... tất cả đều được thực hiện dễ dàng thông qua giao diện thay cho việc dùng dòng lệnh. Thế là chúng tôi nhào vào viết wiki, tạo issues (lúc này ko còn gọi là tickets theo cách gọi của trac nữa)... Mỗi nhân viên của team có 1 issue, gọi là CV của anh A, hoặc issue CV của anh B. Một số dự án lớn thì lại tạo issue riêng để lưu tất tần tật tài liệu, trao đổi... chỉ trong 1 issue đó. Sau này dùng lâu rồi, tôi mới hiểu có đồ chơi là 1 chuyện, nhưng dùng thế nào, cho việc gì và làm sao hiệu quả... thì là 1 chuyện khác.

Đi thẳng vào mục đích/lợi ích của Redmine, sau khoảng 7 năm dùng các hệ thống Issue Tracking riêng (trac, Redmine, JIRA)[4] cũng như module tích hợp trong các hệ thống github, Google Code..., là 1 lãnh đạo cần phải quản lý công việc của nhân viên dưới quyền, tôi nhận thấy Redmine dùng tốt cho 3 mục đích:

• Quản lý dự án. Rất nhiều tài liệu, slides, blog posts trên Internet nói về chuyện dùng Redmine cho việc này. Tôi cũng sẽ đề cập 1 chút vv quản lý dự án nhưng xin hẹn ở 1 chủ đề riêng.
• Quản lý tri thức. Nói tên nghe rất "kêu", nhưng ẩn đằng sau đó chỉ là Wiki mà thôi :D.
• Quản lý vận hành, bao gồm cả những dạng quản lý hỗ trợ (Service Desk). Cái này đối với tôi là tinh hoa của việc vận dụng 1 hệ thống Issue Tracking. Cũng vì gọi chung là Issue Tracking thay vì Project Management mà tôi nhận thấy phải dùng Redmine cho cả việc vận hành/hỗ trợ người dùng này. Nói thêm 1 chút, một trong những thành quả lớn nhất mà tôi đạt được đó là, khi các bạn trong team của tôi nghỉ việc, tôi chỉ việc assign issues cho các bạn khác thay thế mà ko phải lo lắng xem quá trình bàn giao công việc có thiếu sót chỗ nào không. Tuyệt hơn nữa, các bạn mới cũng có thể lục lại những CV đã hoàn tất (closed issues) làm cho quá trình hoạt động của team không bị ngắt quãng, không bị mất thông tin của bất kỳ CV nào (nói thế chứ 1 số CV các bạn đó không lưu nên chuyện mất mát thông tin là vẫn xảy ra).

Tôi cũng quan sát khá nhiều công ty, khá nhiều chuyên gia CNTT, kể cả 1 số công ty tư vấn/kiểm toán quốc tế. Phần đông họ vẫn chỉ cần đến email, 1 số công cụ như Word, Excel, MS Project, Notes... và cảm thấy "đủ". Nhưng cũng khá nhiều nơi đã bị tôi thuyết phục sau khi họ cần tìm giải pháp cho 1 trong 3 vấn đề tôi nêu trên. Đặc biệt có 1 phòng ban trong công ty của tôi đã sử dụng Redmine khoảng 2 năm từ 2013 đến nay, đã lưu và xử lý hơn 15000 yêu cầu hỗ trợ với hơn 1000 người dùng, trên cùng 1 hệ thống dùng chung với team của chúng tôi.

Có lẽ với chừng này thông tin, tôi hi vọng đã thuyết phục được các bạn trong việc quyết định sử dụng Redmine (hoặc 1 hệ thống tương tự như JIRA) với 3 mục tiêu nêu trên. Chúc các bạn dùng công cụ này thành thạo & hiệu quả.

(Bắt đầu bớt email, chuyển sang Redmine thôi!!??!!)

(Còn tiếp)

PS. Khi đọc lại bài viết này, tôi nhận thấy bài viết chưa hay lắm khi tiêu đề nói về Redmine, nhưng đoạn đầu lại đề cập tới trac. Tôi đã thử nhưng thấy bản thân không thể viết lại hay hơn. Bạn đọc xem góp ý nhé.

----

[1]: http://trac.edgewall.org/
[2]: http://www.redmine.org/
[3]: http://trac.edgewall.org/wiki/TracAdmin
[4]: https://en.wikipedia.org/wiki/Issue_tracking_system, https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems