SSE674Project1-Chapter7

=Part II - Chapter 7 =

=1. Describe the risk tracking process goals. Why is each goal important? Define quantitative success criteria for each goal.=

> a. Monitor the events and conditions of risk scenarios. 20% >> By getting regular updates you can monitor and communicate the progress of the risk scenarios.

> b. Track risk indicators for early warning. 15% >> The regular updates will also help you to monitor risk indicators.

> c. Provide notification for triggering mechanisms. 15% >> A notification action should be part of the trigger process. Once an item is identified there should be a list of people to notify so the situation can be addressed.

> d. Capture results of risk resolution efforts. 15% >> The regular update process allows you to capture the resolution efforts.

> e. Report risk measures and metrics regularly. 15% >> By having you team report regularly you can up-channel it to management and keep them updated.

> f. Provide visibility into risk status. 20% >> In the management reports you can represent the data visually in the form of charts so progress is clearly visible.

> Each goal has an impact on the entire project. These goals focus on the monitoring process of risk analysis. Once the risks are established you have to set way to monitor progress and capture results and that’s what risk tracking accomplishes.

=2. Do you think tracking risk scenarios can indicate success or failure of the risk resolution activity? Explain how monitoring risk scenarios increase your certainty over time.=

> Risk tracking scenarios can provide a lot of information. By utilizing risk tracking tools you can automate the tracking process. By using this automation you can set criteria to evaluate and monitor the risks in your project. You can also use these tools to create scenarios to see where you will be at if certain conditions are not met. The use of automated tools gives the project leader to power to predict trends and an ability to focus project objectives based up risk scenario results.

=3. Your project tracking tool has been updated to include the latest software modules completed through unit test. The cumulative earned value indicator fell below the planned threshold. Explain how your tracking progress will react to this event.=

> The time required to monitor risk scenarios is an investment that we make for high-severity risks. Risk scenarios are like threads that string a risk to a problem. The events and conditions in it are the checkpoints along the road to a problem. Risk scenarios are monitored to determine if the problem of risk occurrence is increasing. When it is difficult to see the big picture, risk scenarios can provide evidence that attention is require because the risk is materializing. Events and conditions of a risk scenario are tracked to decide whether the increase in risk exposure justifies immediate action. When status is input =, individual indicators are compared to their planned thresholds. Indicator values outside their accepted norms detect unacceptable conditions and serve as an early warning system.

=4. Explain how triggers can be used to regulate risk action plan execution.=

> A trigger is a devise to control the implementation of a risk action plan. It can be set through the monitoring of status indicators, planned thresholds, quantitative targets, and the project schedule. The variance between planned thresholds and actual status provides information on when to set a trigger. For risk that is within the planned threshold, triggers can signal the closure of the risk resolution activity.

=5. List two types of triggers that can be used to provide notification of unacceptable risk. Give an example of how each trigger can activate a risk action plan. Describe who will be notified, and how they will be notified.=

> a. Relative variance – Is a notification trigger that indicates a range is outside of acceptable values.

> b. Threshold value – Is a notification trigger that indicates a value has crossed a predetermined threshold.

> When a trigger is set, notification is sent to the appropriate personnel through established communication channels.

=6. Discuss the relationship among the key indicators of a software project: progress, size, change, quality, risk, and staff.=

> a. Progress – Earned value measures the amount of work remaining by comparing planned and actual milestone completion. Cumulative months measure the schedule remaining by comparing planned and actual time used. Cumulative dollars measure the budget remaining by comparing the estimated completion cost with the actual dollars spent.

> b. Size – Lines of code measure the software size by counting physical or logical sources statements.

> c. Change – Volatility measures the number of requirements that are added, deleted, or modified. You should expect some requirements growth early in the life cycle.

> d. Quality – The number of defects closed and open measure the errors found and fixed with the number of errors remaining.

> e. Risk – Risk exposure measures the level of unresolved risk.

> f. Staff – Turnover measures the number of staff who leave the team and cause a productivity drop and schedule disruption. New team members, regardless of skills and experience, require time to become familiar with the project and processes. In addition, a productive team member will usually have to devote time to the new hire. Overtime measures the hours over a standard work week that the staff is working. Staff effectiveness decreases when the overtime percentage approaches 20 percent.

=7. No single metric can provide wisdom. Describe the minimum set of metrics that you would recommend to ensure project success.=  > These ate the minimum number of risk measures and metrics every project should have:

>> a. Number of risks >> b. Risk category >> c. Risk severity >> d. Risk threshold >> e. Risk management index

=8. Discuss the consequences of reporting risk metrics that are not timely, validates, economical, or understandable.=

> Obviously the consequences of not reporting risks metrics in a timely manner could get you fired. All projects have customers, either internal or external, that wanted the project in the first place. The project manager is responsible to report frequent project progress to the customer and part of that report is the risk metrics. If the data is late, not accurate, validated, or not understandable then the customer can pull out from the project. If the customer is external to the organization, this would involve a potential financial loss. Businesses are not interested in projects that don’t make money and if you can’t provide correct information to make the customer feel comfortable then you are wasting everybody’s time.

=9. What measures and metrics should be tracked to ensure a cost-effective risk management process?=  > a. Risk exposure > b. Risk leverage > c. Risk indicator > d. Return on investment

=10. How do you think risk management reserve should be monitored? Explain your answer.=

> A risk management reserve is a strategy to use contingency funds and built-in schedule slack. You should utilize these resources to make up time in the project where there is a large schedule slip due to unforeseen events. This schedule and budged reserve must be used cautiously and if at all possible not at all. The problem with using it in the early stages of the project can backfire on you down the road when an major problem happens and the entire project becomes effected.

=11. Do you agree that the greatest potential for control tends to exist at the point where action takes place? Discuss why you do or do not agree.=

> In most cases this is true. It is much easier to manage something that is in the right here and now. When you are in the current process everyone is focused on what is happening and it is at the front of everyone’s mind. While it is not impossible to deal with something that happened earlier in the project It is always more efficient to be dealing with something that is currently the main focus of the team.

 Project Home Next Section