®
IBM Software Group
PRJ480 Mastering the Management of Iterative Development v2
Module 2: Iterative Project Management
© 2006 IBM Corporation
Module 2 Objectives
Understand issues for Project Managers (PM) who use iterative
development by:
Learning how the PM monitors and steers an iterative project
towards success.
Understanding the importance of the following in iterative
development:
 Confronting risk early.
 Using an architecture-first approach.
 Using objective quality control and progress assessment.
Learning the importance of the principal artifacts used by PM.
Understanding how team responsibilities change.
2-2
Team Leadership
 The following are the main elements of team
leadership:
The team framework: putting in place the
appropriate roles, staff assignments, tools,
and processes
The big picture: seeing that the effort
continues to meet the business needs, and
that it has the correct contents, schedule,
and budget
Team dynamics: making sure that the
project team and individuals are
communicating effectively
2-3
Review: Project Navigation
Business-Oriented Goals Achieved
E-end
START
C-end
T-end
I-end
Technically-Oriented Goals Achieved
2-4
Coarse-Grained Versus Fine-Grained Plans
Project Plan
Phase Plan
Iteration Plan (current)
Phases and major
milestones
• What and when
Iterations for each phase
• Number of iterations
• Objectives
• Duration
Work Breakdown Structure
Iteration Plan (next)
Roadmap
Coarse-grained
Plan
2-5
Fine-grained Plans
Work Breakdown Structure Issues
Common Flaws
Solutions
Prematurely structured
around product design
Organize around the process
Prematurely broken down into
Evolve detail over time
too much or too little detail
Structured in a projectspecific way that impedes
cross-project comparisons
Remain consistent in form
across enterprise
2-6
Review: RUP Effort and Time Distribution by Phase
Inception
Elaboration
Construction
Transition
Effort
5%
20%
65%
10%
Time/Schedule
10%
30%
50%
10%
This distribution is typical for new software projects
2-7
Iteration Assessment and Steering
Start Iteration Using
Iteration Plan
Artifact: Iteration
Assessment
Complete Planned
Iteration Work
Assess
Iteration
Reduce
risk
Stop
Continue
Project Stopped
Adjust
Objectives
Accept
change
Adjust Target
Product
Steer
project
Adjust Remaining
Plan
Plan Next
Iteration
Start Next Iteration
Artifact: Iteration
Plan
2-8
Discussion: Iteration Assessment
 What types of information are needed to assess an iteration correctly?
 Under what conditions might you be required to adjust:
Your project objectives?
Your target product?
2-9
Risk Recommendations
Iterative development recommends that you:
 Create a risk list, order it by risk magnitude, and update it as the
project progresses
 Mitigate the highest magnitude risks as early as possible
Exiting Elaboration requires that highest (technical or otherwise)
risks have been mitigated.
2-10
Software Architecture
 Software architecture defines the infrastructure, control, and data
interfaces that permit:
Software components to cooperate as a system
Software designers to cooperate efficiently as a team
 It is the most critical technical product of a software project.
 It encompasses the set of significant decisions about the
organization of a software system.
 It maps the problem to a solution without violating constraints. It
requires innovation and cannot be automated.
2-11
Software Architecture (Cont.)
 Software Architecture is the basis for
decisions relating to:
Make/buy decisions
Component reuse
Intellectual control
 Manage complexity
 Maintain integrity
Project management
 Planning, Staffing, Delivery
2-12
Architecture As a Basis for Project Management
 A stable architecture represents a significant project
milestone.
 Poor architecture is often a reason for project failure.
 Architecture is a prerequisite for predictable planning.
 Architecture is the source of numerous high-payoff / high-risk
decisions.
2-13
Measurements in a Software Development Project
 Measurements provide the development and management teams with:
An assessment of progress to date
Insight into the quality of the evolving software product
A basis for estimating the cost and schedule for completing the
product with increasing accuracy over time
Two perspectives:
 Point values
 Trends of values
2-14
Use of Measurements in Iterations
Start Iteration Using
Iteration Plan
Measurements
Complete Planned
Iteration Work
Assess
Iteration
Stop
Continue
Project Stopped
Adjust
Objectives
Adjust Target
Product
Adjust Remaining
Plan
Measurements are used
to assess iterations.
Plan Next
Iteration
Start Next Iteration
2-15
Seven Core Metrics: Management
METRIC
Work and progress
Budgeted cost and expenditures
Change traffic and stability
PURPOSE
Iteration planning, plans versus actuals,
management indicator
Financial insight, plan versus actuals,
management indicator
Iteration planning, management indicator of
schedule convergence
Breakage and modularity
Convergence, software scrap, quality indicator
Rework and adaptability
Convergence, software rework, quality indicator
MTBF and maturity
Staffing and team dynamics
Test coverage/adequacy, robustness for use,
quality indicator
Resource plan versus actuals, hiring rate,
attrition rate
2-16
Measurement Recommendations
Iterative development recommends:
 Measuring the progress and quality of software products
throughout the development lifecycle
 Extracting information from evolving artifacts, since these are
the most useful measurements
 Using objective analysis and automated data collection, since
these are crucial to the success of any measurement program
2-17
Discussion: Measurements
 Which measurements would you consider essential to iterative
development in your environment? Can you think of any other
measurement that your organization MUST have in addition to this core
set? What is it and why?
 In your last project, how did you adjust (or should you have adjusted)
your objectives? What kind of measurement do you need to adjust your
objectives?
2-18
Work Products
 A work product is an abstract
concept that provides a
generalization for the concrete
work product types Artifact,
Outcome, and Deliverable.
Iteration Plan
Developer
Test
Storyboard
 A work product is:
Iteration
Assessment
Analysis
Model
Business Goal
Produced, modified, or used by a task
Use Case Model
The responsibility of a single role, but
can be modified or used by others
Likely to be subject to configuration
control
 Artifact-type work products may
contain other artifacts
2-19
Architectural
Proof-of-Concept
Test Environment
Configuration
Project
Measurements
Workspace
Tools
User-Interface
Prototype
Business Use
Case Model
Artifacts
 An artifact is a work product that represents a piece of
information that is produced, modified, or used by a process
 Artifacts can be of type:
Model – created using modeling tools, from where we can
automatically create reports
Use Case Model
Document – created using word processors
Iteration Plan
2-20
Generic Artifact Lifecycles
 Evolving – Minor Changes Expected
Example: Vision
Example: Development Case
 Evolving – Major Changes Expected
Example: Requirements Model
 Snap-shot – Newly created for each iteration
Example: Iteration Plan
2-21
Artifacts and their Uses
Artifacts provide:
 Permanent documentation of a system’s
structure and behavior, such as:
Reference manuals, user guides, and
architecture description
Used by end-users, maintainers, and re-users
 Transitory documentation of the development
process, such as:
Internal design documentation
Status assessments
Defect reports
2-22
The goal is to
minimize the
creation of
artifacts.
How Much Documentation is Enough?
A successful project provides documentation sufficient for:
Shared Vision
 Communicate overall vision of project
Risk reduction
 Promote a dialog between stakeholders and developers
Points of control for management
 Make decisions and progress explicit and tangible
Conceptual integrity of the architecture
 Capture and communicate the vision of the software architect/team
2-23
Contrasting Approaches to Artifact Development
Sample
Artifacts
Small Commercial Product
Large System Development
Business Case
Short memo and spreadsheet
Full scope proposal
Vision
Brief concept paper
20-page paper with GUI prototype
Software
Development Plan
10 page overall plan
Development plan, CM Plan, QA
Plan, and so on
Iteration Plan
Kickoff meeting
Detailed scenarios, quality targets,
performance benchmarks, and so
on
Software
Architecture
Document
5 slide presentation
120 page document
Release Notes
In-depth analysis of test results,
measurement results, demos, and
so on
Online help, Sales rollout, and
marketing collateral
Online help and tutorials, user
manual, training course, phased
cut-over plan, advertising
campaign
Iteration
Assessment
Deployment Plan
2-24
Essential Project Management Artifacts
Software Development Plan
Business Case
Deployment Plan
Risk List
Issues List
Review Record
Iteration Plan/ Iteration Assessment
Status Assessment
2-25
Essential Mgt. Artifact: Software Development Plan
 The Software Development Plan includes the following information:
Project Overview
Project Organization
Management Process
 Project Estimates
 Project Plan
 Iteration Plans
 Project Monitoring and Control
Technical and Supporting Process Plans
 Important for gathering all information necessary to control the project, and
for directing the development effort.
2-26
Essential Mgt. Artifact: Iteration Plan
 The Iteration Plan includes the following information:
Task-level Plan
Resources
Use Cases
Evaluation Criteria
 It is important for:
The project manager, to plan the iteration tasks and activities, to
schedule resource needs, and to track progress against the schedule
Project team members, to understand what they need to do, when
they need to do it, and what other activities they are dependent upon
2-27
Essential Mgt. Artifact: Iteration Assessment
 The Iteration Assessment includes the following information:
Iteration Objectives reached
Adherence to Plan
Use Cases implemented
Results relative to Evaluation Criteria
Test Results
External Changes
Rework required
 It is important for the development organization to reflect on what has
happened, what was achieved (or not) and why, and the lessons learned
from the iteration.
2-28
Team Scheduling and Staffing
Phase
Schedule
Staff
Inception
A small team including:
If the project will
• The project manager
last about one
• The system/software architect
year, this phase
will last about one • A member of the test team
• Several developers who will
month.
continue on the project
Elaboration
A small team including:
• The project manager
• The software architect
If the project will
last about one
• A small team of designers and
developers
year, this phase
will last about two
• A small test team
to four months.
• One to two domain experts or
end-users
• Tool specialists
2-29
Team Scheduling and Staffing (Continued)
PHASE
Construction
Transition
SCHEDULE
• If the project will last about
one year, this phase will last
about five to six months.
• For a modest size project,
plan for a new release every
2 to 3 months.
• For a more complex project,
every 6 to 9 months.
• Varies greatly depending on
how the end of the phase is
defined.
• If customer acceptance
marks the end of transition,
then for a one year project,
the transition phase should
not last more than one
month.
• If the end of product life
marks the end of transition,
the transition phase may last
much longer.
2-30
STAFF
• Staffing reaches its peak. 80% of
the team should be directly
contributing to the release.
• The remaining 20% are performing
tasks that address new risks and
prepare the ground work for next
releases.
• The software manager
• The software architect (part-time)
• A small team of developers and
testers
• Technical support personnel
• A technical writer (to update
documentation)
• Marketing, manufacturing, trainers,
and other support personnel
RUP Distribution of Skills by Phase
Table shows percentage of effort by activity for each phase.
Inception
%
Elaboration
%
Construction
%
Transition
%
Management
14
12
10
14
Environment/CM
10
8
5
5
Requirements
38
18
8
4
Design
19
36
16
4
Implementation
8
13
34
19
Assessment
8
10
24
24
Deployment
3
3
3
30
100
100
100
100
Total
2-31
Iterative Project Management Issues
 Overly detailed planning up to the end
Detailed plans outdate quickly
Incorporate precision commensurate with knowledge of current
activities
 Progress based upon completion of artifacts
Artifacts are poor predictors of project completion
Concentrate on code completion instead
 Too many iterations
A build is not an iteration release
Keep iteration durations to a minimum of about 1-2 months
2-32
Iterative Project Management Issues
 Change in responsibilities and perspective of team
members and clients
Analysts
Developers
Testers
Project Manager
Quality Assurance and Method Expert
Client
2-33
Exercise: Collegiate Sports Case Study
Refer to Exercises section of your workbook and complete:
Exercise 1: Project Planning
2-34
Module 2 Review

A Project Manager must monitor and steer an iterative project
towards success by regularly assessing and re-planning.

Three concepts important for an iterative lifecycle are:

Addressing risk early

Stabilizing architecture early

Using objective measurements

Use of artifacts should be kept to a minimum, and the decision
should be made about artifact evolution.

Important iterative project management artifacts are:


Software Development Plan

Iteration Plan

Iteration Assessment
Team responsibilities evolve through phases and iterations, so
staffing and scheduling must evolve.
2-35
2-36