Managing Risk in Software Project
Risk Planning
Plan how to manage the project’s risks: The Risk Management Plan documents how risks will be managed. It is a subset of the project plan and is written before the project begins.
Risk Identification
Identify risks: One simple approach is to get representatives of all the affected groups in a room and have a workshop. Circulate a provisional list to excite attention. Get their ideas down onto large sheets of paper you can blu-tack to the walls. Circulate a revised list after the meeting.
Repeat the process half-way through the project, and identify how many have not occurred, and how many unforeseen ones had occurred.
Risk Alerts
Risk Alerts are the triggers used to identify when a risk is imminent. Typical test-related triggers are:
1. Reduction in the number of lines of code per bug found.
2. Finding an unacceptably-high number of priority-1 and -2 bugs in a build.
3. Finding an unacceptably-high number of bugs in a component.
4. Late arrival of signed-off specifications for use as a baseline.
5. Failure of performance tests to achieve targets.
6. Growing code complexity.
7. Growing code turmoil.
Monitoring such risks is easier when an alerting system is in place. The existence of a risk log allows the test team to identify priorities and provides a good basis for deciding the mix of tests to be planned.
Risks can be grouped by sources and by kinds and a risk kind is for example that something doesn’t work, that it works too late, too slowly, at the wrong time, or that it has unintended side-effects. These groups are sensitive to risk drivers in that a driver can change a whole group of risks.
The failure of the project to use an appropriate development method was having a knock-on effect throughout the whole of the project. It was a source of risks and a major driver. Here are some more are
1. Use of an inappropriate (unrelated to the risk) method or process.
2. Lack of customer involvement:Apart from the obvious need for a sufficient set of requirements
3. There is the need for feedback to users of (fragments of) the proposed solution.
4. Dissimilarity to previous projects: If “we’ve never done anything as (big/complex/different) as this before” is an issue, then beware.
5. Project complexity: This is relative to the experience of an organization. What might exhaust some organizations will be run-of-the-mill to others.
6. Requirements volatility: If such changes aren’t allowed for, the project will soon deteriorate.
