08/07/2013 – Blogs of Prof. John Vu, Carnegie Mellon University
– This article is translated into Vietnamese by Ngo Trung Viet with the English
originals followed.
Quản lí rủi ro đóng vai trò then chốt trong xác định thành công
của dự án phần mềm. Phần lớn việc quản lí dự án bao gồm xác định rủi ro, lập kế
hoạch biện pháp phòng ngừa, giám sát rủi ro, và giải quyết với thay đổi. Bằng
việc hiểu quản lí rủi ro, người quản lí dự án có thể tránh và giảm tác động của
rủi ro, cung cấp ước lượng lịch biểu và ngân sách tốt hơn và chung cuộc làm
tăng sự thoả mãn của khách hàng.
Quản lí rủi ro bao gồm việc nhận diện rủi ro, thẩm định hậu quả
của rủi ro, xác định giải pháp, và lấy hành động. Cùng với những bước này, trao
đổi liên tục và theo dõi rủi ro giúp cho người quản lí dự án vẫn ở trên ngọn
các thay đổi. Để nhận diện rủi ro, người quản lí có thể xem xét các vấn đề dự
án điển hình như rủi ro kĩ thuật, rủi ro nhân sự và rủi ro ước lượng. Bên cạnh
rủi ro chung có thể có các rủi ro đặc thù duy nhất cho dự án. Bất kì dữ liệu lịch
sử hay bài học rút ra từ dự án tương tự đều có thể có ích trong nhận diện các rủi
ro duy nhất này. Bảng rủi ro có thể hữu dụng trong việc thẩm định các rủi ro có
khả năng xuất hiện thế nào và tác động sẽ lớn đến đâu. Dựa trên thông tin này,
kế hoạch có thể được thực hiện để giảm nhẹ và giải quyết rủi ro. Rủi ro có thể
xuất hiện hay rủi ro sẽ gây ra tác độnglớn nên được quan sát chặt chẽ và đề cập
sớm nhất có thể được. Rủi ro càng được giảm nhẹ sớm, tác động càng đỡ bị phí tổn.
Ước lượng rủi ro là thông thường trong dự án phần mềm bởi vì khó
dự đoán chính xác việc phát triển sẽ mất bao lâu. Người quản lí dự án có thể
theo dõi tiến độ thực tế qua lịch biểu để xác định liệu dự án có đúng mục tiêu
không. Rất thường là thay đổi trong yêu cầu sẽ xuất hiện và vấn đề với việc
phát triển cũng sẽ nảy sinh. Những thay đổi này là một phần của quản lí rủi ro
bởi vì chúng đặt ra căng thẳng cho lịch biểu và đưa dự án vào rủi ro không hoàn
thành được đúng hạn. Để giải quyết với những thay đổi không tránh khỏi, qui
trình kiểm soát thay đổi cần có tại chỗ. Việc này đảm bảo rằng các thay đổi được
giám sát cẩn thận và những người có liên quan không mất cái nhìn về mục đích
chính.
Kĩ năng thương lượng giữ một phần then chốt trong khả năng của
người quản lí dự án giải quyết các thay đổi. Người quản lí dự án phải cân bằng
sự thoả mãn của nhân viên và sự thoả mãn của khách hàng bằng việc xem xét cả
hai khi đánh giá thay đổi yêu cầu và lịch biểu. Thay đổi có thể được đề cập tới
bằng việc điều chỉnh tài nguyên, thời gian, chi phí hay chức năng. Điều này yêu
cầu mặc cả với khách hàng và có lẽ cả với nhân viên để xác định giải pháp tốt
nhất. Ưu tiên cũng phải được xác định để phát triển và cập nhật bản kế hoạch hiện
thực.
Trong dự án phần mềm người quản lí dự án đương đầu với thay đổi
và vấn đề bởi vì bản chất phức tạp của phát triển phần mềm họ có thể dùng kĩ
năng quản lí rủi ro để ngăn ngừa vấn đề và giải quyết chúng. Điều này bao gồm
nhận diện rủi ro, thẩm định chúng, xác định giải pháp, lấy hành động và thường
xuyên giám sát dự án. Qui trình quản lí rủi ro này cũng với ước lượng tốt và kĩ
năng thương lượng tạo khả năng cho người quản lí dự án giải quyết với những
thay đổi không tránh khỏi xảy tới trên đường.
Rủi ro xảy ra trong mọi lĩnh vực, không chỉ phần mềm. Đây
là ba ví dụ minh hoạ cho vấn đề liên kết với rủi ro.
1) Công nghiệp xây dựng: Rủi ro phụ thuộc
Dự án xây dựng thường bao gồm nhiều nhà thầu chuyên môn những
người làm việc cùng nhau để xây nhà mới. Thời gian của nhà thầu thường phụ thuộc
vào các công nhân khác điều có thể tạo ra rủi ro nếu như có nút thắt cổ chai. Nếu
mọi người làm nền móng không hoàn thành, bạn không thể xây được tường và cột, bạn
không thể đặt mái. Những phụ thuộc này nên được xác định sớm nhất có thể được
và được giám sát để điều chỉnh lịch biểu khi cần thiết.
2) Công nghiệp ô tô: Rủi ro thay đổi thị trường
Tin tức gần đây đã chỉ ra thay đổi thị trường đã tác động thế
nào lên các dự án của ngành công nghiệp ô tô. Mặc dầu xe lớn đã từng phổ biến
trong những năm gần đây; nhu cầu về xe hơi có hiệu quả nhiên liệu đã tăng lên.
Những rủi ro này đặc biệt khó dự báo nhưng chúng có thể có tác động khổng lồ và
nên được giám sát và đề cập nếu có thể được.
3) Nghiên cứu và phát triển thuốc : Rủi ro thực nghiệm
Thực hiện qui trình quản lí rủi ro là thách thức với nghiên cứu
và phát triển thuốc vì có mức độ phức tạp và bất định cao. Nỗ lực có thể được
đưa ra các bằng chứng về khái niệm mà có thể được dùng hay không được dùng. Những
nỗ lực này có thể là khó dự báo và dễ dàng làm thay đổi chi phí và lịch biểu.
Ví dụ về bảng rủi ro cho dự án phần mềm.
Rủi ro
|
Phân loại
|
Xác suất
|
Tác động
|
Lưu ý
|
|
1
|
Ước lượng kích cỡ có thể thấp
|
Rủi ro dự án
|
55%
|
Găng
|
Ước lượng kích cỡ có thể cần được điều chỉnh.
|
2
|
Ngân quĩ có thể bị giảm đi 15%
|
Rủi ro khách hàng
|
40%
|
Lớn
|
Chức năng có thể cần được giảm bớt dựa trên danh sách ưu tiên..
|
3
|
Dự án phức tạp
|
Rủi ro công nghệ
|
45%
|
Găng
|
Phần phức tạp của phần mềm có thể mất nhiều thời gian để hình
dung ra. Điều này có thể làm nảy sinh việc điều chỉnh lịch biểu.
|
4
|
Học công nghệ mới
|
Rủi ro công nghệ
|
85%
|
Găng
|
Người phát triển sẽ học công nghệ mới mà sẽ làm chậm tiến độ
lúc khởi đầu.
|
5
|
Nhiều người có liên quan tham gia
|
Rủi ro khách hàng
|
35%
|
Lớn
|
Sẽ khó làm hài lòng mọi người có liên quan và các yêu cầu có
thể thăng giáng lớn.
|
6
|
Nhu cầu thị trường có thể thay đổi
|
Rủi ro tác động doanh nghiệp
|
25%
|
Lớn
|
Nhu cầu về phần mềm quản lí dự án nào đó có thể thay đổi sớm.
Điều này có thể làm nảy sinh các yêu cầu chức năng khác.
|
7
|
Thay đổi cán bộ
|
Rủi ro con người
|
15%
|
Lớn
|
Việc thay đổi cán bộ là không cao vào từng lúc nhưng nó là rủi
ro phải được giám sát.
|
8
|
Thay đổi phạm vi
|
Rủi ro ước lượng
|
75%
|
Găng
|
Bởi vì có nhiều người có liên quan tham gia nên rủi ro thay đổi
phạm vi là cao. Qui trình thay đổi tốt có thể giúp giải quyết rủi ro này.
|
9
|
Phụ thuộc bên ngoài vào chuyển giao phần cứng
|
Rủi ro tác động doanh nghiệp
|
30%
|
Găng
|
Có phụ thuộc phần cứng là găng cho dự án này. Nếu có chậm trễ
trong chuyển giao, lịch biểu sẽ phải được điều chỉnh.
|
10
|
Phần khoán ngoài của dự án
|
Rủi ro dự án
|
35%
|
Lớn
|
Dự án được khoán ngoài cho nên rủi ro được liệt kê dưới thấp sẽ
nhân lên trong thẩm định rủi ro..
|
______________________________________
Giáo sư John Vu, một người Mỹ gốc Việt, là một nhà khoa học nổi
tiếng nước Mỹ thuộc trong Top 10 những người sáng tạo nhất thế giới. Ông từng
là Phó Chủ tịch của Boeing. Sau khi rời Boeing, GS John Vu hiện là viện trưởng
Viện Công Nghệ Sinh Học ÐH Carnegie Mellon. Ông là dịch giả/tác giả bộ sách
Hành Trình về Phương Ðông, Ðường Mây Qua Xứ Tuyết, Ngọc Sáng Hoa Sen, Trên Ðỉnh
Tuyết Sơn,… và cuốn mới nhất 2016 là Khởi Hành.
______________________________________
—-English version—-
Risk Management
Risk management plays a key role in determining a software
project’s success. A large part of managing a project consists of
determining risks, planning prevention measures, monitoring risks, and dealing
with changes. By understanding risk management, project manager can
avoid and reduce the impact of risks, provide better schedule and budget
estimations and ultimately increase customer satisfaction.
Risk management consists of identifying risks, assessing
consequences of risks, determining solutions, and taking action. Along
with these steps, continuous communication and risk tracking helps project
managers stay on top of changes. In order to identify risks, managers can
consider typical software project issues such as technical risks, personnel
risks and estimation risks. In addition to common risks there can be
specific risks unique to a project. Any historical data or lessons
learned from similar projects can be helpful in identifying these unique
risks. A risk table can be useful in assessing how likely risks will
occur and how big the impact would be. Based on this information, plans
can be made to mitigate and handle the risks. Risks that are likely to
occur or risks that will cause a great deal of impact should be watched closely
and addressed as early as possible. The earlier that risks are mitigated,
the less costly the impact.
Estimation risks are commonplace in software projects because it
is difficult to accurately predict how long development will take. A
project manager can track the actual progress versus the schedule to determine
if the project is on target. Most likely changes in requirements will
occur and issues with development will arise as well. These changes are
part of risk management because they place a strain on the schedule and put the
project at risk for not being completed on time. In order to deal with
the inevitable requirement changes, a change control process needs to be in
place. This ensures that changes are carefully monitored and stakeholders
don’t lose sight of main goals.
Negotiation skills play a key part in a project manager’s
ability to handle changes. A project manager must balance employee
satisfaction and customer satisfaction by considering both when evaluating
requirement and schedule changes. Changes may be addressed by adjusting
resources, time, cost or functionality. This requires bargaining with the
customer and perhaps employees to determine the best solution. Priorities
must also be determined to develop an updated realistic plan.
Though software project managers encounter changes and issues
because of the complex nature of software development they can use risk
management skills to prevent issues and handle them. This includes
identifying risks, assessing them, determining solutions, taking action and
constantly monitoring the project. This risk management process
along with good estimation and negotiation skills enables project managers to
deal with the inevitable changes that come up along the way.
Risk happened in every field, not just software. Here are three
examples that illustrate the problems associated with risk.
1) Construction
industry: Dependency risks
Construction projects often consist of many specialized
contractors who work together to build a new house. The contractors’
timelines often depend on other workers which can create risk if there is a
bottleneck. If people work on the foundation is not finish, you can not
build walls and without walls and columns, you can not put on the roof These
dependencies should be determined as early as possible and monitored in order
to adjust the schedule as necessary.
2) Automobile
industry: Market change risks
Recent news has shown how market changes have impacted the
automobile industries’ projects. Though large vehicles have been popular
in the recent years; the demand for fuel efficient cars has increased.
These risks are particularly difficult to predict but they can have a huge
impact and should be monitored and addressed if possible.
3) Pharmaceutical
research and development : Experimentation risks
Implementing a risk management process is challenging for
pharmaceutical research and development projects because there are high degrees
of complexity and uncertainty. Effort can be put towards proofs of
concept that may or may not be used. These attempts can be difficult to
predict and easily change costs and schedules.
1. Example
for Risk table for a software project .
Risk
|
Category
|
Probability
|
Impact
|
Notes
|
|
1
|
Size estimates may be low
|
Project risk
|
55%
|
Critical
|
Sizes estimates may need to be adjusted.
|
2
|
Funding may be reduced by 15%
|
Customer risk
|
40%
|
Significant
|
Functionality may need to be reduced based on a
prioritized list.
|
3
|
Complex project
|
Technology risk
|
45%
|
Critical
|
Complex parts of the software may take time to figure
out. This may result in adjusting the schedule.
|
4
|
Learning new technology
|
Technology risk
|
85%
|
Critical
|
Developers will be learning new technology which will slow
down progress initially.
|
5
|
Many stakeholders involved
|
Customer risk
|
35%
|
Significant
|
It will be difficult to please all stakeholders and
requirements may fluctuate greatly.
|
6
|
Market demand may change
|
Business Impact risk
|
25%
|
Significant
|
The demand for certain project management software may change
soon. This may result in different functional requirements.
|
7
|
Staff turnover
|
People risk
|
15%
|
Significant
|
The staff turnover is not high at the moment but it is a risk
that should be monitored.
|
8
|
Scope creep
|
Estimation risk
|
75%
|
Critical
|
Because there are so many stakeholders involved the risk for
scope creep is high. A good change process can help with this risk.
|
9
|
External dependency on hardware delivery
|
Business Impact risk
|
30%
|
Critical
|
There is a hardware dependency that is critical to this
project. If there is a delay in delivery, the schedule will have to be
adjusted.
|
10
|
Outsourcing part of the project
|
Project risk
|
35%
|
Significant
|
Part of the project is outsourced so the risk listed below
will factor into the risk assessment.
|
________________________________________
Đọc thêm về Tủ Sách
Vietnam Carenet TẠI ĐÂY
Đọc thêm các bài viết
về Khởi Nghiệp TẠI ĐÂY
Đọc thêm các bài viết
về Lập Kế Hoạch TẠI ĐÂY
Đọc thêm các bài viết
về Lập Dự Án TẠI ĐÂY
Đọc thêm các bài viết
về Quản lý Dự Án TẠI ĐÂY
Đọc thêm các bài viết
về Kỷ Nguyên 4.0 TẠI ĐÂY