Software Project Management: Risk Management
2 likes4,534 views
Software Project Management: ResearchColab- Risk Management (Document-7) Presented in 4th year of Bachelor of Science in Software Engineering (BSSE) course at Institute of Information Technology, University of Dhaka (IIT, DU).
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to Software Project Management: Risk Management (20)
![4.1software Project Management - Risk management^J Managing [Autosaved].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/4-250427092515-cd00ca7a-thumbnail.jpg?width=560&fit=bounds)
Ad
More from Minhas Kamal (12)
Recently uploaded (20)
Software Project Management: Risk Management
- 1. i ResearchColab Risk Management Team: Reckless 7 Institute of Information Technology University of Dhaka 25th November, 2016
- 2. Contents 1.1 Introduction.....................................................................................................3 1.2 Project Risk Management...............................................................................3 1.3 Risk Identification...........................................................................................3 Risk Category................................................................................................4 Schedule........................................................................................................4 Requirement Risk..........................................................................................4 Project Management Risk.............................................................................4 Product/Technology Risk..............................................................................4 Customer Risk...............................................................................................4 Human Resources & Contractors Risk .........................................................5 1.4 Risk Register...................................................................................................5 1.5 Heat Map.........................................................................................................8 1.6 Evaluating Risks .............................................................................................9 1.7 Monitoring and Review ..................................................................................9 1.8 Conclusion ....................................................................................................10
- 3. 3 1.1 Introduction Risk is inevitable in a business organization when undertaking projects. However, the project manager needs to ensure that risks are kept to a minimal. Risks can be mainly divided between two types, negative impact risk and positive impact risk. Not all the time would project managers be facing negative impact risks as there are positive impact risks too. Once the risk has been identified, project managers need to come up with a mitigation plan or any other solution to counter attack the risk. 1.2 Project Risk Management Managers can plan their strategy based on four steps of risk management which prevails in an organization. Following are the steps to manage risks effectively in an organization: Risk Identification Risk Quantification Risk Response Risk Monitoring and Control 1.3 Risk Identification Managers face many difficulties when it comes to identifying and naming the risks that occur when undertaking projects. These risks could be resolved through structured or unstructured brainstorming or strategies. It's important to understand that risks pertaining to the project can only be handled by the project manager and other stakeholders of the project. Risks, such as operational or business risks will be handled by the relevant teams. The risks that often impact a project are supplier risk, resource risk and budget risk. Supplier risk would refer to risks that can occur in case the supplier is not meeting the timeline to supply the resources required. The common Project Risk List Reference below which are divided into a number of risk categories are samples of potential risks of a project may be exposed to and should only be used by the Project Team as a reference and starting point for risk identification during the project risk management planning. The category of risks identification is listed below-
- 4. 4 Risk Category Risks Schedule 1. Schedule not realistic, only "best case". 2. Important task missing from the schedule. 3. A delay in one task causes cascading delays in dependent tasks. 4. Unfamiliar areas of the product take more time than expected to design and implement Requirement Risk 1. Requirements have been base lined but continue to change. 2. Requirements are poorly defined, and further definition expands the scope of the project 3. Specified areas of the product are more time-consuming than expected. 4. Requirements are only partly known at project start 5. The total features requested may be beyond what the development team can deliver in the time available. Project Management Risk 1. PM has little authority in the organization structure and little personal power to influence decision-making and resources 2. Priorities change on existing program 3. Project key success criteria not clearly defined to verify the successful completion of each project phase. 4. Projects within the program often need the same resources at the same time 5. Date is being totally driven by need to meet marketing demo, trade show, or other mandate; little consideration of project team estimates Product/Technology Risk 1. Development of the wrong user interface results in redesign and implementation. 2. Development of extra software functions that are not required (gold plating) extends the schedule. 3. Requirements for interfacing with other systems are not under the team’s scope. 4. Dependency on a technology that is still under development lengthens the schedule. 5. Selected technology is a poor match to the problem or customer Customer Risk 1. Customer insists on new requirements. 2. Customer review/decision cycles for plans, prototypes, and specifications are slower than expected. 3. Customer insists on technical decisions that lengthen the
- 5. 5 schedule. 4. Customer will not accept the software as delivered even though it meets all specifications. 5. Customer has expectations for development speed that developers cannot meet. Human Resources & Contractors Risk 1. Critical development work is being performed by one developer 2. Some developers may leave the project before it is finished. 3. Hiring process takes longer than expected. 4. Personnel need extra time to learn unfamiliar software tools, hardware and programming language. 5. Contract personnel leave before project is complete. 6. Conflicts among team members result in poor communication, poor designs, interface errors and extra rework. 7. Personnel with critical skills needed for the project cannot be found. 8. Contractor does not deliver components when promised. 1.4 Risk Register A risk register or risk log is a scatter plot used as risk management tool and to fulfill regulatory compliance acting as a repository for all risks identified and includes additional information about each risk, e.g. nature of the risk, reference and owner, mitigation measures. Severity and likelihood of the project will be scaled in the following ways- Categorized Harm Severity Severity Level Risk Normal 1 Very Low Negligible 2 Low Marginal 3 Moderate Critical 4 High Catastrophic 5 Extreme Where, Catastrophic – Multiple Deaths Critical – One Death or Multiple Severe Injuries Marginal – One Severe Injury or Multiple Minor Injuries Negligible – One Minor Injury Normal - Less Than Injury
- 6. 6 Likelihood Category Likelihood Level Less Likely 1 Likely 2 Very Likely 3 A table of Risk Register is given below- Potenti al Risk Dimen sion Ref . No Risk Scope (Inter nal/E xtern al) Attribut es Description Sever ity Like liho od Risk Plan Priorit y Status Requ ireme nts 1.1 Exte rnal Maintai nability Continually changing requirements 5 3 Add effort on requirement analysis with collaboratio n. High Closed 1.2 Inter nal Plannin g System requirement not adequately identified 4 2 Give a dummy project view at first. High Closed 1.3 Exte rnal Plannin g Unclear system requirements 5 2 More meeting required with stockholders High Closed 1.4 Inter nal Depend encies Project involves the use of new technology 3 1 Required experts or train existing tem members Medi um Closed Team 2.1 Inter nal Depend encies Inexperience team members 4 1 Assign experienced project manager Medi um Closed 2.2 Inter nal Depend encies Inadequately trained development team members 3 2 More meeting required with stockholders High Closed 2.3 Inter nal Depend encies Team members lack of specialized skill required 5 1 Continuous meeting and monitoring High Closed
- 7. 7 by the project User 3.1 Exte rnal Maintai nability Users resistance to change 3 2 Consult with User and project team Medi um Closed 3.2 Exte rnal Maintai nability Users with negative attitudes toward the project 3 1 Consult with User and project team Medi um Closed 3.3 Exte rnal Maintai nability Conflicts between users 4 1 Consult with User and project team High Closed Proje ct comp lexity Plann ing & Cont rol 4.1 Inter nal Resour ces Lack of effective project management technology 4 2 Project planning should be done keeping in mind about existing tools and technology Medi um Closed 4.2 Inter nal Monito ring Project progress not monitored closely enough 5 1 Project managemen t and team collaboratio n should be increased Medi um Closed 4.3 Inter nal Plannin g Inadequate estimation of required resources 3 2 Backup equipment should be ready Low Closed 4.4 Inter nal Plannin g Poor project planning 5 1 Assign experienced project manage Medi um Closed Orga nizati onal Envir onme nt 5.1 Inter nal Maintai nability Change in organizationa l management during the project 4 1 Consult with User and project team Medi um Closed
- 8. 8 5.2 Exte rnal Depend encies Corporate politics with negative effect on the project 2 2 Continuous meeting and monitoring Low Open 5.3 Inter nal Monito ring Unstable Internal Communicati on environment 3 3 Signed off the agreement with detailed. Medi um Closed 1.5 Heat Map Visualization is a powerful tool for simple information risk analysis. The simple of act of placing risks in special relationship to each other allows a quick overview of essential elements of your risk profile. As importantly, it allows you to communicate that simple risk profile to others that aren’t as versed in information security, IT, and information management. A popular risk visualization tool is an information risk heat map. The heat map for our project is given below- Figure1.5: Heat Map CatastrophicCritical 1.15.3 5.2 1.32.2, 3.1, 4.3 1.2, 4.1 2.3, 4.2, 5.1, 5.2 1.4, 3.2 2.1, 3.3 High Medium Low Normal Negligible Marginal PotentialImpact Probability
- 9. 9 1.6 Evaluating Risks The risk evaluation step involves deciding whether the identified risk is acceptable, after considering:- The controls already in place The cost impact of managing the risks or leaving them untreated Benefits and opportunities presented by the risk The risks borne by other stakeholders During this process, the risk rating identified during the analysis step, is compared against all other risks and assigned priority for each risk. 1.7 Monitoring and Review Regular monitoring and review of risks is an important part of the ResearchColab program. It ensures that new risks are; detected; added to the Risk Register, managed and that action plans are implemented and progressed effectively. The key to the monitoring process is to establish a cost, schedule, and performance management indicator system over the entire program that the PM uses to evaluate the status of the program. The indicator system should be designed to provide early warning of potential problems to allow management actions. Risk monitoring is not a problem-solving technique, but rather, a proactive technique to observe the results of risk handling and identify new risks. Test and Evaluation (T&E), Earned Value (EV), Technical Performance Measurement, Program Metrics & Schedule Performance Monitoring are Some monitoring techniques which can be adapted to become part of a risk indicator system. Risk mitigation strategies and specific action plans should be incorporated in the project execution plan, or risk analyses are just so much wallpaper. Risk mitigations was planned and has been executed according to given below- Characterized the root causes of risks that had been identified and quantified in earlier phases of the risk management process. Evaluated risk interactions and common causes. Identified alternative mitigation strategies, methods, and tools for each major risk. Assessed and prioritized mitigation alternatives. Selected and committed the resources required for specific risk mitigation alternatives. Communicated planning results to all project participants for implementation.
- 10. 10 Although risk mitigation plans developed in detail and executed by project manager and team members, the project management developed standards for a consistent risk mitigation planning process. Risk mitigation planning was continued beyond the end of the “ResearchColab” project by capturing data and lessons learned that can benefit for our future projects. 1.8 Conclusion In fine it can be added that, software risk management, risks classification in this project, are clearly described. If risk management process is in place for each and every software development process then future problems could be minimized or completely eradicated. Hence, understanding various factors under risk management process and focusing on risk management strategies explained above could help in building risk free products in future. Risk management is an on-going process, and is a combination of proactive management directed activities within a program that are intended to accommodate the possibility of failures. So, it should be controlled in standard way.