08 Jan, 2021
Quản lý rủi ro
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.. |
—-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. |