© ITU, April 10
Iterative Project Management
© ITU, April 10
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.
© ITU, April 10
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
© ITU, April 10
Review: Project Navigation
START
I-end
E-end
T-end C-end
Business-Oriented Goals Achieved
Technically-Oriented Goals Achieved
© ITU, April 10
Coarse-Grained Versus Fine-Grained Plans
Phases and major milestones
• What and when
Iteration Plan (next) Iteration Plan (current)
Fine-grained Plans Phase Plan
Iterations for each phase
• Number of iterations
• Objectives
• Duration
Work Breakdown Structure
Coarse-grained Plan Project Plan
Roadmap
© ITU, April 10
Work Breakdown Structure Issues
Common Flaws Solutions
Prematurely structured
around product design Organize around the process
Prematurely broken down into
too much or too little detail Evolve detail over time Structured in a project-
specific way that impedes cross-project comparisons
Remain consistent in form
across enterprise
© ITU, April 10
Review: RUP Effort and Time Distribution by Phase
This distribution is typical for new software projects
Inception Elaboration Construction Transition
Effort
5% 20% 65% 10%
Time/Schedule
10% 30% 50% 10%
© ITU, April 10
Iteration Assessment and Steering
Start Iteration Using Iteration Plan
Start Next Iteration Complete Planned
Iteration Work
Adjust Objectives
Adjust Target Product
Adjust Remaining Plan
Plan Next Iteration
Project Stopped Stop
Assess Iteration
Continue
Artifact: Iteration Assessment
Artifact: Iteration Plan Reduce
risk
Accept change
Steer project
© ITU, April 10
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?
© ITU, April 10
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.
© ITU, April 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.
© ITU, April 10
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
© ITU, April 10
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.
© ITU, April 10
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
© ITU, April 10
Use of Measurements in Iterations
Measurements are used to assess iterations.
Start Iteration Using Iteration Plan
Start Next Iteration Complete Planned
Iteration Work
Adjust Objectives
Adjust Target Product
Adjust Remaining Plan
Plan Next Iteration
Project Stopped Stop
Assess Iteration
Continue
Measurements
© ITU, April 10
Seven Core Metrics: Management
METRIC PURPOSE
Work and progress Iteration planning, plans versus actuals, management indicator
Budgeted cost and expenditures Financial insight, plan versus actuals, management indicator
Change traffic and stability 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 Test coverage/adequacy, robustness for use, quality indicator
Staffing and team dynamics Resource plan versus actuals, hiring rate, attrition rate
© ITU, April 10
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
© ITU, April 10
Discussion: Measurements
• Which measurements would you consider essential to iterative development in your environment? Can you think of any other measurement that your organization MUSThave 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?
© ITU, April 10
Work Products
• A work product is an abstract concept that provides a generalization for the concrete work product types Artifact, Outcome, and Deliverable.
• A work product is:
– Produced, modified, or used by a task – 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
Iteration Plan Developer
Test
Tools Storyboard
Project
Measurements Workspace
Business Use Case Model Business Goal
Iteration Assessment
Analysis Model
Architectural Proof-of-Concept Use Case Model
Test Environment Configuration
User-Interface Prototype
© ITU, April 10
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 createreports
– Document– created using word processors
Iteration Plan Use Case Model
© ITU, April 10
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© ITU, April 10
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
The goal is to minimize the creation of
artifacts.
© ITU, April 10
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
© ITU, April 10
Contrasting Approaches to Artifact Development
20-page paper with GUI prototype Brief concept paper
Vision
Online help and tutorials, user manual, training course, phased cut-over plan, advertising campaign Online help, Sales rollout, and
marketing collateral Deployment Plan
In-depth analysis of test results, measurement results, demos, and so on
Release Notes Iteration
Assessment
120 page document 5 slide presentation
Software Architecture Document
Detailed scenarios, quality targets, performance benchmarks, and so on
Kickoff meeting Iteration Plan
Development plan, CM Plan, QA Plan, and so on
10 page overall plan Software
Development Plan
Full scope proposal Short memo and spreadsheet
Business Case
Large System Development Small Commercial Product
Sample Artifacts
© ITU, April 10
Essential Project Management Artifacts
– Software Development Plan – Business Case
– Deployment Plan – Risk List – Issues List – Review Record
– Iteration Plan/ Iteration Assessment – Status Assessment
© ITU, April 10
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.
© ITU, April 10
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
© ITU, April 10
Iteration Plan Example
• Shows timeframes and resources by discipline
Outline of an Iteration Plan
Iteration Schedule section for Requirements discipline
© ITU, April 10
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.
© ITU, April 10
Team Scheduling and Staffing
Phase Schedule Staff
Inception
If the project will last about one year, this phase will last about one month.
A small team including:
• The project manager
• The system/software architect
• A member of the test team
• Several developers who will continue on the project
Elaboration
If the project will last about one year, this phase will last about two to four months.
A small team including:
• The project manager
• The software architect
• A small team of designers and developers
• A small test team
• One to two domain experts or end-users
• Tool specialists
© ITU, April 10
Team Scheduling and Staffing (Continued)
PHASE SCHEDULE STAFF
Construction
• 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.
• 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.
Transition
•Varies greatlydepending 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.
• 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
© ITU, April 10
RUP Distribution of Skills by 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
Total 100 100 100 100
Table shows percentage of effort by activity for each phase.
© ITU, April 10
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
© ITU, April 10
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
