Risk
|
Probability of this risk becoming an issue
|
Potential consequence to the project
|
Potential consequence to the organization
|
Mitigation strategy
|
Conflicting resource assignments; for example, resources assigned to several projects at the same time.
|
Highly likely for the initial adoption of the iterative development practice.
Rarely occurs in agile environments where team colocation, multi-disciplinary team members, and shorter
schedules minimize this risk.
|
Iteration will not meet its objectives.
|
In traditional software development cultures, when critical resources have conflicting assignments, the
project manager will tend to create detailed plans for the entire duration of the project in an effort
to secure resources.
This approach goes against the fundamental scheduling model of the iterative development practice,
where only the coming iteration is planned in detail, while the remaining iterations are planned at a
higher level of detail.
This approach will also create the wrong expectation with the leadership team with respect to the
progression of projects managed using iterative methodology.
|
Devise a resource allocation strategy that reduces conflicting project assignments and leverages
knowledge of specialized resources.
1. Use specialized resources as mentors, providing guidance to several teams, which can span several
projects.
2. Develop a prioritization process that allows team members to receive clear direction on the tasks
that have highest priority.
|
Projects acquire highly specialized resources on a full-time basis to carry out most complex tasks on
projects.
|
Highly likely during the initial adoption of the iterative development practice.
Less likely when team members are generalizing specialists [AMB03] who can take on multiple roles.
|
Project bears increased labor costs because either highly skilled talent will carry out less complex
work after they finish their primary work, or those resources will be under-allocated.
Increased risk of creating a bottleneck around the work outputs of the specialized resources.
Increased scrutiny of the executives' team.
|
This potential consequence applies to both traditional and agile cultures.
Highly specialized resources dedicated to a single project cause ineffective use of critical
organizational capacity.
Unavailability of the specialized resources for other project work affects progress negatively, causing
executives to interfere with prioritization and project assignments.
|
Mitigation plan defined above also applies to this risk.
Develop a training program to encourage and enable resources to learn complementary skills and
competencies so that they can take multiple roles on the project.
|
Project manager has limited experience with iterative development practice.
|
Highly likely during the initial adoption of iterative practices.
Less likely to be a problem for agile teams that are typically more autonomous and require less
direction.
|
Poor iteration planning.
Slower than required resolution of issues during and across iterations, affecting the desired project
velocity.
|
During the initial adoption of the iterative development practice, executives will expect tangible
results to justify the new direction. An inappropriately skilled or inexperienced project manager
will not generate the desired results and might jeopardize the commitments of the executive team to
iterative development.
|
This risk is so high and its impact so far-reaching that an effective mitigation is required.
1. Hire an experienced project manager (part- or full-time) with the required skills and
experience.
2. Develop a coaching or mentoring program for project managers who are new to iterative
development.
|
Team has limited experience with iterative development practice.
|
Highly likely, especially when iterative development practices are introduced.
Less likely among agile teams that tend to adopt iterative development more naturally.
|
Traditional style: The team becomes uncertain. Waiting or needing to be told what to do reduces
team productivity.
Agile style:
The team might not collaborate optimally.
|
Perception is that iterative development takes more time rather than less time.
Perception is that iterative development is chaotic.
|
In either situation, provide a coach or mentor for teams that are new to iterative development.
Provide mechanisms that the teams can use to evaluate their adoption of iterative development practice,
such as retrospective reviews.
|
Team wants to "extend" the iteration.
|
Highly likely in organizations that are used to delivering their executables at the end of a project.
Less likely in organizations where executable code is frequently delivered during the course of a
project.
|
Iterations will not be carried out in a time-box framework, thus reducing the required velocity,
generating longer overall schedules, and increasing the cost of the project.
|
Teams do not reap the benefit of seeing early, continual progress. Members begin to think that
iterative development is not different than anything they have done in the past.
|
Ensure strong project management skills to re-enforce the construct and benefits of time-box iteration
planning and execution.
|
Teams do not deliver executable code at the end of each iteration (except the very first iteration in
large projects).
|
Highly likely in organizations that are used to delivering their executable code at the end of a
project.
Less likely in organizations where frequent code delivery is the norm.
|
Less risk reduction achieved by the iteration.
Reduced ability to obtain fresh input from client so as to incorporate feedback from one iteration to
the next.
|
Iterative development is perceived as not being different from what has been done in the past.
|
Include demonstrations of executable code to sponsors and clients into the plans for every iteration.
Broadcast, communicate, and celebrate the success of each demonstration.
For larger projects, begin the demonstrations with the second iteration.
|
Stakeholders not available to give feedback iteration by iteration.
|
Depends on organizational culture.
|
Problems with requirements or expectations will not be discovered until the end of the project, when
they are more expensive to fix.
|
Iterative development is perceived as not being different from what has been done in the past.
|
Involve stakeholders early in planning cycle, secure key stakeholder commitments during project
schedule review, and communicate the benefits of early feedback.
Create an internal feedback group to review the results from each iteration.
|
Iterative development is used as a stand-alone practice rather than in concert with risk-reduction
practices.
|
Moderate.
|
Although projects will obtain the benefit of early feedback, showstopper issues might emerge far later
in the project, when they are more costly to resolve.
|
Late-in-the-game showstopper issues increase the perception that iterative development is not different
from what has been done in the past.
|
Discuss and demonstrate to the executive team the benefits and insist on the need to use iterative
development practice in conjunction with risk-reduction practices.
|