• (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.
Sách:
http://en.wikipedia.org/wiki/Identifying_and_Managing_Project_Risk
Tham khảo thêm:
http://www.failureproofprojects.com/Risky.pdf
Picture: http://www.flickr.com/photos/wonderlane/2048849866/
No comments:
Post a Comment