This chapter is from the book
This chapter is from the book
This chapter is from the book
3.6 Approaching Development Risk
One way that people think about development projects is an exercise in risk management. Some consultants on risk management recommend that the team identify all of the possible risks, usually through some sort of brainstorming session, and then ensure the risks are mitigated. While understanding and addressing the risks of your project is important, it is best to have a more structured way of thinking about risks in your projects.
People can only think about seven things at a time [Miller, 1956]. Given the complexity of software development, it is important to focus on the right things. A useful way to identify and track the issues in managing a software project is to track a small number of development risks.
The literature on software risk analysis is extensive and typically overly elaborate: lists of hundreds of possible risks; bureaucratic procedures that consist of risk management plans, brainstorming sessions with risk identification, and periodic assessments. Most of this is wasted effort. In the spirit of keeping things simple, you should focus on the three project risks:
Schedule risk: Not delivering the project on time
Cost risk: Exceeding the budget before you deliver the project
Quality risk: Delivering software that fails to meet stakeholder needs
Other so-called risk items such as staffing risk (the inability to staff) or technical risk (uncertainty about how to design the code) put the project at risk only to the extent that they affect schedule, cost, or quality. For example, the inability to staff is only a problem if it will put the schedule at risk.
3.6.1 Schedule Risk
The product development perspective addresses schedule risk in three ways:
It provides insight into the progress of the software development. By tracking the progress of the actual product and not trying to gauge completion of the activity, the manager can determine the true schedule variances. This accurate and timely insight enables the manager to address schedule risk.
It provides ongoing integrations and prototypes. Because this approach supports evolving versions of the software rather than integration at the end, technical risk is distributed throughout the effort rather than being stacked at the end.
It provides phases with planned milestones. Planned milestones provide momentum for completion of the effort. The defined phases with specified completion criteria allow the manager to keep the team focused on the dates. The phases help keep the project from spiraling out of control.
3.6.2 Cost Risk
The attributes of the product development perspective that help address schedule risk also apply to cost risk. In addition, the manager can prioritize content throughout the development. Iterations are planned so that the most essential features are addressed early. As development progresses, the manager can drop unessential features as necessary to hold to the budget, based on cost/benefit tradeoffs. In contrast, the systems engineering approach does not provide the mechanisms for making such tradeoffs once the specifications are written.
3.6.3 Quality Risk
The product development method addresses quality risk in several ways. The underlying approach is to find a solution to the development that satisfies the product needs. The manager can keep the team focused on the system architecture as the solution evolves. Finally, with good schedule and cost management, the team will not be scrambling to patch together a solution at the end of the project. They will have time to address the quality attributes.
The manager can review the software with stakeholders at each iteration of the evolving software. Necessary changes and tradeoffs can be made throughout the project. The product development approach does not rely on perfect knowledge and understanding at the beginning of the project.