ReadyNotes

Sample Selection

CHAPTER 2

T2.7 Adjust for Risk

Before moving ahead, you need to adjust the labor hours for risk. Risk as used within the context of the Guide refers to exposure to loss. The approach we recommend is to start by assuming there is no risk. Then, factor risk into the estimate so that you can determine its impact. Risks can impact your effort predictions in many ways. The trick to figuring out what risks your cost estimate is most sensitive to is to classify them as either controllables or noncontrollables. Controllables are risks that you can handle through your own management actions. For example, you can have an experienced team assigned when the schedule is tight if you own the people. As Table 3 shows, more capable teams are more productive especially when schedules are tight. In contrast, noncontrollables are risks that you have limited or no control over. For example, marketing might be changing the requirements to accommodate key client accounts. When pressed, they argue that the changes in features are needed in order to satisfy the market. There is nothing you can do to stop the changes. The best you can do in this situation is to put a rigorous requirement tracking process into place to manage the changes instead of wasting your effort trying to stop marketing from making changes.

------------------------------------------------------------------------------------------------------------

Lesson Learned No. 15 – To factor risk into your estimate, use the concept of controllables and noncontrollables to focus effort on things that you can do something about. Do not waste your time and effort on risks which are outside your control and you have no influence over. Instead, focus on risks that you can mitigate and you will be able to make a difference.

------------------------------------------------------------------------------------------------------------

Let us illustrate the concept by factoring risk into the robot controller example. Let us assume we did a risk assessment and identified the risks summarized in Table 11. Such risks should not surprise you because most of them are common to many of the software developments you have probably been involved with. As the table shows, we first classified them as controllables and noncontrollables. Then, we developed a mitigation strategy for each item understanding that we should focus energy on those that are controllable. Finally, we quantified the impact of the risk with and without the strategy in force by estimating the cost impact using our productivity formulas as shown in Step 6 of the process illustrated in Figure 1. The Table makes the following points:

*   Many risks in software development can be anticipated. You can mount proven mitigation actions for these risks assuming that you have the budget authority to do so.

*  The way to get management to agree to your risk mitigation strategy is to let them know the impact of their decisions on projected effort and duration. When faced with these negative alternatives, they might be less stringent with their budgets [Putnam].

*   Risks that are controllable are exposures to loss that you have the ability to control through the reassignment of personnel or expenditure of assigned budget.

*   Even though risks may be non-controllables, you can build a case for your mitigation strategy by using the numbers to show how you can reduce their negative impacts.

Let us assume that you briefed management and they agreed to the risk mitigation strategy summarized in Table 11. The net effect of this action is a twenty-four percent reduction in effort from 59,840 to 45,695 hours. You will be provided a team averaging seventeen people to get the job done. The questions you need to ask yourself are:

*   Are the people that I will get through my actions really that much better than the norm or am I kidding myself?

*   Will these people be made available to me in a reasonable time period (i.e., good people are normally busy and in high demand on their existing projects)?

*   Can I absorb these new people without negatively impacting my team’s existing productivity
(i.e., it takes time and effort to make these people productive on the project)?

 

Table 11.  Robot Controller Risk Matrix

Risk

Controllable or Non-Controllable

Mitigation Strategy

Impact with Mitigation

Aggressive schedule

Non-controllable – set by customer

Assign best people instead of assuming nominal profile for staff

24% productivity improvement

Difficulty in staffing up

Controllable

Press management to free up staff based upon potential delays in delivery due to lack of staff

Able to meet schedule

Feasibility of software requirements

Controllable

Set expectations with marketing and customer base about what functionality is realistic to achieve within time period

Able to deliver base functionality in first release

Growth in functionality

Controllable

Continue to re-enforce expectations – delay added functionality until next release

Able to deliver

as promised

Lack of management visibility

Controllable

Take the time to prepare a detailed project plan comprised of milestone schedules. Manage work at root level.

No surprises relative to progress

Quality of product questionable

Controllable

Put a quality assurance program in place, institute peer reviews and use defect metrics to determine when you have tested enough

Quality of product acceptable upon delivery

No money available for capital gear

Non-controllable – budget set by management

Do what you can with equipment and tools that you already have at your disposal.

Produce more with less – can show benefits

 

If the answers to any of these questions about staff are “no,” you should pursue actions different from those that appear in the Table. You should fight for more experienced staff by arguing that they would increase the chances that you could satisfy the schedule. You should decrease productivity and argue that the norm apply unless you are assured that you can get better people assigned when you need them. Having the names of the people you want and transition agreements in place with other projects helps when trying to secure such promises from senior management. In other words, be prepared when arguing for resources.

------------------------------------------------------------------------------------------------------------

Lesson Learned No. 16 – To quantify risk, first estimate the cost without considering it. Then, factor risk into the estimate to determine its impact by looking at the variation in cost and schedule. If the variation is minor, the risk is not severe and you should be able to control it without raising the flag to senior management

------------------------------------------------------------------------------------------------------------

Purchase, Product Descriptions, Author Bios, Table of Contents