Quản lý risk trong thực tế

[Sarah conner]

Dear all,
Trong thực tế áp dụng, em thấy khá khó để khẳng định là dự án đã xác định đầy đủ các rủi ro chưa, có nhiều PM còn tự tin là dự án của mình chả có rủi ro nào cả :|. Khi phân tích các dự án đã triển khai, phần nhiều các nguyên nhân dẫn đến chậm deadline, over budget...thì lại k phải là KHÔNG THỂ LƯỜNG TRƯỚC ĐƯỢC .
Các anh chị có thể chia sẻ giúp về kinh nghiệm quản lý risk trong thực tế của mình không?
Tks all:shaking:

 

[dovi]

Tôi dịch lại bải này để bạn hiều thêm về RISK
Project Cost Estimate
Tôi đang có kế hoach đi chơi Bali, ở 1 khách sạn, đển ngắm nhiều nơi và mua sắm với vài chổ thú vị. chi phí cho ký nghỉ (project) bao gồm:
- vé máy bay: 500 USD
- Tiền Khách sạn: 1000 USD
- ăn uống: 2000USD
- Mua sắm: 1000 USD
- Thuê xe: 500 USD
Tất cả chi phí "roll up": $5000. (không bao gồm siêu mẫu-ca sĩ K.N.Th, người mẫu-diễn viên điện ảnh T.N. diễn viên-ca sĩ N.K...)
Đây là Project Cost Estimate của tôi.

Risk
Tôi chưa từng đế Bali, và cũng chưa ra nước ngoài, Nên nhiều rủi ro sẽ liên lụy đến chuyến đi này của tôi.

PMBOK 4th, định nghĩa rủi ro là sự kiên không chắn chắn ( an uncertain event). nếu nó sảy ra., nó sẽ anh hưởng đến mục tiêu dự án. mục tiêu có thề bao gồm: phạm vi, tiến độ, chi phí và chất lượng. Một rủi ro có thể có một nhiều nguyên nhân và nếu xảy ra nó có thể nó có vài ảnh hưởng. Một nguyên nhân có thể là yêu cần, giả định, ràng buộc , điểu kiện nó tạo ra kết quả hay hậu quả (negative or positive outcomes)

It's not all negative

Chú ý rằng 2 từ khóa: negative or positive. Từ điển định nghĩa từ "risk" là tiêu cực theo nghĩa rộng
Vì vậy, nó là ít trực quan để nghĩ rằng rủi ro có thể hiểu rủi ro là tích cực (positive)

Rủi ro xấu và Đe dọa

Bạn nghĩ điều gì sẽ sai trong chuyến du lịch của bạn, tôi kể vài thứ:

- bị bệnh (đau)
- bị trôm
- Mất ví, Passportm hành lý..
- Hết tiền
- Bị bắt cóc
- Cá mập/ Cá xấu xơi thịt
- Bị chết đuối hay giết
- THời tiết không thuận lợi
- Bị thiên tai (Natural calamity)

Rủi ro tích cực và cơ hội

Vâng, nếu tôi may mắn, mọi thứ có thể biến thành tốt hơn mong đợi. Là gì
cơ hội ở phía trước? Tôi có thể:
- Khám phá cơ hội kinh doanh
- Gặp gỡ một người bạn cũ
- Nhận phòng khách sạn và thuê xe giá tốt
- Trúng xổ số
- Khám phá một kho tàng ẩn tại một trong các bãi biển từ xa Bali

Chiến lược cho các rủi ro tiêu cực hoặc các mối đe dọa
Đó là những nguồi rủi ro thực sự dành nhiều nỗ lực và nguồn trên? Có bất kỳ rủi ro mà tôi loại bỏ (tránh)? Tôi có thể làm một cái gì đó để làm giảm
tác động hoặc xác suất (giảm thiểu) của một số rủi ro? Tôi có thể chuyển rủi ro cho một ai đó khác? Hãy xem.

• Bệnh
- Bảo hiểm y tế để trang trải chi phí themedical (chuyển rủi ro đến các công ty bảo hiểm)
-Tiêm vắc xin,..phòng tránh: phòng bệnh hơn chữa bệnh
- mang theo đồ sơ cứu khi bị bệng (giảm thiểu)
- Giữ số điện thoại khẩn cấp bệnh viện địa phương và dịch vụ tiện dụng (giảm thiểu)

• Bị cướp
- Có được bảo hiểm du lịch (chuyển chi phí rủi ro cty bảo hiểm)
- Giữ số điện thoại khẩn cấp địa phương tiện (giảm thiểu)
- không mang theo vật có giá trị cùng (tránh)

• Bị mất ví tiền, hộ chiếu
- Nhận bảo hiểm du lịch (chuyển chi phí rủi ro để công ty bảo hiểm)
- Giữ soft-copy các giấy tờ (giảm nhẹ).

• Hết tiều đột suất
- sử thè tín dụng.

• Cá mập/ cá xấu xơi thịt
- Mặc áo bảo vệ ((mitigate)

• Thời tiết xấu
- chọn mùa đi chơi thích hợp và theo dõi dự báo thời tiết ((mitigate)

• Thiên tai
- Mua bả hiểm

Chiến lược cho rủi ro thuận lợi hoặc cơ hội (Opportunities)

Tôi có thể làm tăng cơ hội có phòng khách sạn tốt và thuê xe với giá hời?
Tôi sẽ làm gì với kho báo( the treasure) nếu tôi bao giờ khám phá ra? Hãy xem nhe.

• Một good-deal về khách sạn và thuê xe
Hãy thử để lên kế hoạch chuyến đi trong off-season(enhance)

• Trúng số
Mua vé số hằng ngày

• Khám phá ra kho báo
làm từ thiện trước để tích phước (share)

Và cỏn Residual Risks, Contingency Plans, Contingency Reserves, Risk Triggers... sẽ dịch sau hoặc bạn đọc bản tiếng anh sẽ hiểu rõ hơn, sorry vì khả năng tiếng anh tầm cỡ "Lậm Văn Sai" của mình.
http://www.deepfriedbrainproject.com/2010/01/project-risk-management-terms-explained.html

 

[aube]

Từ kinh nghiệm của mình thì mình quan tâm nhất tới những rủi ro sau:

Rủi ro đến từ lãnh đạo: Sẽ có những tình huống cơ bản sau:
+ Các bác không biết mình muốn gì, nay muốn một kiểu, hôm sau muốn một kiểu. Nhiệm vụ của PM phải làm sao hiểu được ý các sếp. Truyền thông liên tục để manage expectation
+ Hoặc nhiều bác cá tính, thích làm theo ý của mình. Mình gặp trường hợp sếp Tổng lại thích trực tiếp đưa ra yêu cầu cho một chương trình trên máy tính, mà đáng ra việc này phải giao cho một chuyên gia trong mảng đấy làm.=> dẫn đến nếu là theo ý sếp thì chắc chắn không ra cái gì, mà không làm theo sếp thì ai ra đấy chịu trách nhiệm???

Rủi ro đến từ thị trường: Mình nghĩ, hiểu biết của mình, hoàn toàn khác xa với điều kiện thực tế của thị trường. Việc này đỏi hỏi PM làm trong lĩnh vực gì phải thật sự am hiểu, phải cảm nhận được thị trường, môi trường xung quanh dự án thì mới làm được. Mình đã gặp phải tình huống thực: dự tính sẽ outsource một phần dự án ra ngoài, budget, scope thế này thế kia... nhưng thực tế là không thể outsource được dự án vì thị trường quá ít người biết sử dụng công cụ đấy. Cuối cùng phải chuyển hướng, tuyển quân về đào tạo từ đầu để làm.

Rủi ro đến từ thay đổi các giả thiết (assumptions): thay đổi mang tính định hướng (cực kỳ quan trọng), thay đổi về yêu cầu, thay đổi milestones, thay đổi về ngân sách...Những cái này thì trách nhiệm của ông nào thì cứ gửi mail confirm, ký tên đóng dấu để sau này quy trách nhiệm thoai

 

[vuhung]

Em xin chia sẻ một chút:

1. Risk coi IT như là một dịch vụ trong tổng thể dự án
http://en.wikipedia.org/wiki/IT_risk

2. Phân tích sâu hơn về Risk dưới khía cạnh quản lý dự án
http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf

# Guideline, các ví dụ củ thể cho nghành ICT chứ không phải toy examples.

 

[gauto988]

http://en.wikipedia.org/wiki/Identifying_and_Managing_Project_Risk

Theo như Tom Kendrick nhóm thì có 3 loại nhóm risk : Scope Risk, Schedule Risk và Resources Risk..Các nhóm Risk lại bao gồm các Risk cụ thể được chỉ mặt đặt tên.

Có bác nào có forum có quyền này không? Nếu có thì liệu có thể share cho mọi người được ko?

 

[gauto988]

Aube: Mình nghĩ "Rủi ro đến từ thị trường" thuộc level cao hơn, hình như thuộc portfolio Management.
trong PMBok ở Table 1-1. Comparative Overview of Project, Program, and Portfolio Management:
Scope của Portfolio Management có nêu: "Portfolios have a business scope that changes with the strategic goals of the organization." Như vậy "Rủi ro đến từ thì trường" sẽ do Portfolio Management Handle, từ đó sẽ update xem project có meet với requirement hiện tại hay ko? Ở mức tồi tệ nhất sẽ close dự án(do objective của dự án ko còn met với thực tế yêu cầu), nếu còn thì có phải change scope ko? Nếu change Scope thì đây thuộc nhóm Scope Risk ở level Project Management.

Theo mình hiểu là thế, mong các bác chém nhẹ tay

 

[vuhung]

Sách:
https://dl.dropbox.com/u/28025272/Identifying___Managing_Project_Risk.pdf
Tham khảo thêm:
http://www.failureproofprojects.com/Risky.pdf

Các nguyên nhân thất bại chính là:

• (Scope) The project deliverable, as defined, is infeasible.
• (Schedule, Resource) The project deliverable is possible, but the timing and resource objectives are insufficient for delivery.
• (Control, Monitor) The project is poorly planned, chaotic, and badly managed.

Đây chỉ là các nguyên nhân chính. Theo kinh nghiệm bản thân, em thấy là đúng.

Lần ngược lại phương pháp luận mà tác giả xây dựng PERIL database, có thể thấy rằng số mẫu dữ án (387) tương đối nhỏ, chủ yếu là IT/Solution.

Những người được hỏi để xây dựng dữ liệu cho PERIL chỉ chỉ ra những nguyên nhân *chính* ảnh hưởng (lớn) tới dự án hoặc/và làm dự án thất bại.

Em nghĩ các nguyên nhân "phi kỹ thuật", đòi hỏi tới các kỹ năng mềm như nhân sự hay communication rất khó được nhìn ra bởi PM (nhưng dễ dàng hơn với PMO) và khó viết ra hơn. Do đó, tác giả không tập hợp được đủ các lý do này.

Nhìn lại thống kê trong PERIL, có thể thấy scope là yếu nhân chính ảnh hưởng xấu tới dự án.
# Kinh nghiệm cá nhân trong nghành IT: Bằng mọi giá, không để scope phình ra ngoài mong muốn
# http://nguyenvuhungvietnam.wordpress.com/2012/05/22/project-management-protect-scope-at-any-cost/

"Change scope creep" là nguyên nhân chính trong "change risk".

"Change risk" có impact lớn hơn hẳn so với "defect risk".
# Trong nghành ICT, defect/bug có thể thỏa hiệp nhưng change request phải thực sự thận trọng và đôi khi phải gay gắt (dưới cương vị PM) để bảo vệ dự án (thực tế là bảo vệ mọi stakeholders)

Với PERIL và kết hợp với dữ liệu tổng kết sau khi close các dự án, em nghĩ sẽ dễ dàng retrospective lại tổ chức, portfolio, dự án dễ hơn.

 

[vuhung]

IMO, PMO và PM sẽ phối hợp để giảm thiểu rủi ro do thị trường, đối thủ cạnh tranh, chiến lược, tổ chức, tài nguyên... là những khía cạnh mà PM không thể nhìn thấu đáo và tổng thể.