Developing and Controlling Risks

< Free Open Study >

Developing and Controlling Risks The following are examples of key engineering development risks and treatments: Unrealistic budget and schedule Track all estimates and actuals; understand the team's performance level; Understand how all team members' time is spent�there are always overhead activities in any organization; Don't allow the client to talk you into an unrealistic estimate. Personnel shortfalls Plan for training in areas needed for the project; Establish a learning pattern for team members throughout the project's life; Cultivate teaming relationships with knowledgeable parties. Developing wrong capabilities Insist on meeting with the customer; Prototype and demonstrate planned approaches. The project risk management plan will contain all the identified risks and mitigation plans where appropriate. The risk response development can handle identified risks in three ways: Accept�do nothing. Accept consequences in an active or passive fashion. Transfer. Move the loss to a third party through a contract, get a warranty, or buy insurance. Mitigate. Reduce the impact or probability by using contingency planning or a reserve, or eliminate the cause by using alternative software development strategies. Prepare appropriate responses for each risk item by answering these questions: Who is responsible for the action? When is the action due? What is the metric to watch? What is the metric trigger value? Table 18-2 shows a risk response table for the top ten project risks. Each risk has an identifier and a description. The metric value to watch is shown along with the trigger. For each risk, the value exceeds or is equal to the trigger. This type of table should be reviewed on no less than a weekly basis. Table 18-2. Risk Response Table ID Risk Item Trigger Value Risk Exp. Resolution Approach Who Date 1 Too few engineering experts 10 12 630 Contract now for more PM 1/15 2 Design schedule tight 25 28 450 Enforce Delphi estimates PM ongoing 3 Report function weak 20 25 180 Review with customer Project Leader 2/15 4 Interface too different 10 20 150 Review with customer Project Leader 2/15 5 New requirements 5 5 150 Review cost each time PM ongoing 6 "Goldplating" threat 15 15 120 Hold to requirements document Project Leader ongoing 7 Unknown quality 3 6 60 Get second supplier PM 2/1 8 Wall unstable 10 6 60 Investigate braces Engineer 2/15 9 Timing problems 5 6 30 Simulate and test Engineer ongoing 10 New technology risky 5 8 10 Review with chief scientist Project Leader by stage Risk response management requires a regular review of all risks for changes. The top ten risks are reviewed on at least a weekly basis. They may be the same as the risks on the response table, as shown in Table 18-3. The difference in the two tables is that probability and loss are shown as the components of the risk exposure. Table 18-3. Top Ten Software Project Risks ID Risk Item Prob Loss Risk Exp. Resolution Approach Who Date 1 Too few engineering experts 70 9 630 Contract now for more PM 1/15 2 Design schedule tight 50 9 450 Enforce Delphi estimates PM ongoing 3 Report function weak 20 9 180 Review with customer Project Leader 2/15 4 Interface too different 25 6 150 Review with customer Project Leader 2/15 5 New requirements 30 5 150 Review cost each time PM ongoing 6 "Goldplating" threat 30 4 120 Hold to requirements document Project Leader ongoing 7 Unknown quality 10 6 60 Get second supplier PM 2/1 8 Wall unstable 10 6 60 Investigate braces Engineer 2/15 9 Timing problems 5 6 30 Simulate and test Engineer ongoing 10 New technology risky 5 2 10 Review with chief scientist Project Leader by stage

< Free Open Study >