Page 220 -

11 - PROJECT RISK MANAGEMENT

demonstrations of working, deliverable software, and retrospective meetings) that also lend themselves to proactive
response to risks as follows:

• Daily stand-up meetings. From a risk management perspective, the purpose of daily stand-up meetings
is for the team to identify new risks, issues, and signs of potential trouble, which if left unchecked could
become real threats to the project. Daily stand-up meetings also overcome the risk that team members
will not prioritize their time productively or will be unable to solve technical issues without coordination
with other team members.
Asking whether there are any issues or impediments blocking progress can surface new project risks
for the development team because today’s issues could become tomorrow’s risks and problems. So
it is important to pay attention to the issues being raised and enter any appropriate issues to the risk
register and undertake the necessary risk assessment steps. Also, when the team reports “impediments
to progress” at the daily stand-up meetings, these may be candidates for potential problems (i.e., risks),
so the risk management plan should account for the iterative nature of review and identification of risks.

• Retrospective meetings. Retrospective meetings that regularly review the project for work that went
well in addition to work that did not go well are good vehicles for identifying risk for a software project.
Over the course of a project, adaptive software development teams use tools such as risk burndown graphs
and risk profiles to illustrate the effectiveness of the risk-driven approach. The goal is to rapidly reduce risks on
the project. During a retrospective meeting immediately following an iterative cycle, a team may close out risks
that have been eliminated and reevaluate the likelihood of risks occurring or recurring during the next period.
• Software prototype feedback. Prototype evaluations reveal stakeholder concerns with the proposed
solution, which can result in technical and schedule risks. Addressing the concerns will likely require
updates to the release and iteration plans and reprioritization of risk mitigations.
• Training. Adaptive life cycles provide some techniques for good risk management but they do not insulate
software projects from risks. Indeed, if an adaptive approach is new to an organization, then its introduction
will be a risk; anything new represents a risk of misapplication, misunderstanding, confusion, and failure.
Having an active project sponsor and informed stakeholder involvement; selecting a project manager, team
leaders, and team members with experience using the adaptive approach; and scheduling time for team
training are common techniques to overcome the risk of introducing new methods and processes.

11.6.3 Control Risks: Outputs

The outputs for controlling risks in Section 11.6.3 of the PMBOK Guide are applicable outputs for controlling
®
risks of software projects, with the following extension in Section 11.6.3.4 of this extension.

11.6.3.1 Work Performance Information

®
See Section 11.6.3.1 of the PMBOK Guide.

212 ©2013 Project Management Institute. Software Extension to the PMBOK Guide Fifth Edition
®