16 Critical Software Practices    Adopt Continuous Program Risk Management     Bad Excuses Related to Risk Management

We have no risk.    Give us an hour and we'll tell you our top ten risk items.     Making risks public will kill the program.     The customer goes ballistic whenever he/she hears of a potential problem.    We deal with problems as they arise.     My customer doesn't want to hear that he/she is the source of risk.   Identifying risks is bad for my career.     This is development--why should we worry about supportability and maintainability risks?     How can you predict what will happen a year from now?    Our planning horizon is six months.     No one on the staff knows how to do risk management.    We plan to start implementing risk management next year, after we define the process and train the staff.     Our job is to develop software, not fill out bureaucratic forms.     The commercial software industry doesn't waste time on risk management.     We don't need a separate risk management program because we have frequent technical interchange and Integrated Product Team (IPT) meetings.     If I gave a realistic assessment, no one would listen.     That external interface is not in our risk management program because the interface is not our responsibility.     Using that tool is not a risk. The vendor's salesman said so.    That method is proven and therefore not a risk. The speaker at the conference said so.     People outside the project who don't understand the context will invent worst-case scenarios.     The program is too small to do risk management.     Corporate management won't buy in.     My tech people will rebel if we identify as a risk betting our success on an unproven new technology.     My tech people will rebel if we identify as a risk a lack of skills needed to do development.   We have no cost or schedule risk because new technology will enormously increase our productivity-by five to ten times.     New technology we have never used before will mitigate the risk.     We have to bid the lowest cost to win; we'll worry about doing the job when we get it.     If we bid everything we do, we would lose the project. It's a delivery-order contract.     We can't identify risks based on industry metrics because our process is different.     You have to cut corners to win the program.     We don't mitigate software risk in systems engineering trade studies for embedded systems because software is only a component of subsystems.     Our methodology is Rapid Application Development (RAD), so we have no schedule risk.   Our methodology is evolutionary development, so requirements volatility is not a risk.     We don't include anyone from our hands-on software development staff in risk identification because we have hired an outside consultant as a risk expert.     We don't include anyone from our hands-on software development staff in risk identification because our managers are using a generic risk database to identify risk.    We don't include anyone from our hands-on software development staff in risk identification because they don't have the big picture.    A prime contractor is not behaving like a prime if people from a subcontractor organization participate in risk identification.     There is no risk in the planned big increase in our software staff because of the large layoffs by defense contractors during the past few years.   top