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,
multidisciplinary team members, and shorter schedules minimize this
risk.
|
Iteration will nott 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 underallocated.
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.
|