Download Chapter 7

Iterative Project
Management
Chapter 7.1 – Evolution and Phase Planning
Modified considerably by your Instructor
Objectives
• Understand how to plan the phases of an iterative project
• Understand how to review the progress made during a
phase
• Understand how many iterations a project should have
• Understand what should be delivered by each phase
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
2
Introduction to Evolution / Phase Planning
• Interesting quote: “If a man will begin with certainties, he shall end in
doubts, but if he will be content to begin with doubts, he shall end in
certainties.” Sir Francis Bacon.
• OK, so we’re into project planning and we are looking into evolution
planning in particular.
• But there are many decisions to be made to develop the plan.
– What should go into which phase?
– How will you know when a phase is done?
– How many iterations should there be in each phase?
– What does each iteration need to achieve for subsequent iterations to
safely proceed?
– Which requirements and which risks should each iteration address?
– How can you organize all this to deliver maximum business value
with the time ;/ resources allocated to the evolution?
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
3
More intro…
• To answer these, we need to develop a plan for the evolution.
– Needs to overview the iterations, their goals, major requirements and
risks, and a strategy for how / when we can make critical decisions.
– Thus many questions must now be addressed as part of the
development (evolution) plan.
– First of all, the evolution plan must describe
• Phase activities and Phase milestones
• Number of iterations per phase and iteration milestones
• Must also develop estimates of time / resources needed across the
evolution’s life cycle.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
4
Review: Phases and Their Purpose – all about RISK!
We know that phases provide an objective measure of the ‘state’ of the project based on risk
To review:
Phase
Focus
Inception
Confirm the scope and objectives of the project and bring
the business risks under control
Elaboration
Stabilise the product plans and bring the architectural
and technical risks under control
Construction
Build the product and bring the logistical, project
execution risks under control
Transition
Deliver the product and bring the roll-out risks under
control
The phases define a risk-driven lifecycle
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
5
Breadth and Depth Across the Phases – a Word of Caution
• Very easy to emphasize breadth at expense of depth and vice versa.
• Need a balanced approach where breadth is used to drive the
major decisions and depth used to actively attack specific risks.
• Breadth by itself – used to drive major decisions
–
–
–
–
–
–
–
To understand the problem and define the architecture
Here, entire problem domain is analyzed
All use cases identified
Architecture totally built – ensuring no use-cases break it.
Elaboration produces complete paper specification;
No implementation until Construction
Resembles waterfall.
• Depth by itself – used to jump on and mitigate specific risks.
–
–
–
–
To develop executable releases and really drive out the risks.
Here, take a narrow slice of problem domain; select a few use-cases
Individually analyzed, designed, and implemented in isolation
But leads to a brittle solution where change is not isolated.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
6
The Phase Approach Varies By Phase, as ‘required.’
Phase
Breadth
Depth
Inception
Wide and shallow to gain an
understanding of the scope
Narrow and deep, if an
architectural proof-of-concept is
built
Elaboration
Mostly wide and shallow to
make sure the architecture
covers the breadth
Selectively narrow and deep to
attack risk areas with depth
Construction
Transition
Narrow and deep to develop
and deliver functionality
Filling in the missing pieces
based on feedback and bugs
Balance is required, in the early phases, to create a
firm foundation for the rapid development of the solution
Many unsuccessful projects stress one over the other.
Successful projects balance the need for breadth and depth across the lifecycle.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
7
The Type of Release Produced Varies By Phase
• Iterations result in development of an executable release.
• We know this, but the type of release varies by phase.
• Inception and Elaboration releases are prototypes.
– Maybe throwaways to illustrate something or
– May be something to form basis of actual deliverable release later
– Not suitable for general release.
• Construction releases may become deliverable releases.
– They have qualities required of a deliverable product.
– Been tested, documented, no stubs, should do something useful.
– If necessary, could be deployed.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
8
The Type of Release Effort Expended By Phase
Effort Directly
Contributing to
the Release
Phase
Unit of Delivery
Type of
Release
Inception
Generic Proof of
Concept
Proof of
Concept /
Prototypes
< 20%
Elaboration
Scenario /
Abstract Flow of
Events
Architecture
Release
> 50%
Construction
Flow of Events /
Use Case
Deliverable
System
> 80%
Emergency
Fixes
Usable
System
c. 40%
Transition
Note: The final column sums up the amount of effort that is directly contributing to the release
produced by the iteration. These figures are indicative only.
The rest of the effort is spent on: Management, Groundwork, Environment, Training,
Secondary Tasks, New risk investigations, impact analysis, User Support, Meetings
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
9
Phases: Effort and Schedule
• Risks mitigated varies by phase.
• Thus effort required will vary across the phases.
• Project extending capabilities of an existing solution
– Much less business risk (than one building a new product.)
– Inception phase of projects like these will differ significantly.
• project developing a new and unprecedented technology
– a lot of technical risk (than one using an existing architecture).
– Elaboration phases of projects such as these will vary quite a bit.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
10
Typical and More Difficult UP Projects
Number of iterations for illustration only; Resource levels across phases – typical.
Height of bar represents the proportion of project resources; length: proportion of time.
Effort 65%
Resources
10%
Effort 20%
5%
Inception
– 10%
Elaboration
– 30%
Construction
– 50%
Transition
– 10%
Time
In this figure, more time is spent in inception due to
more business matters needing scrutiny and control. Effort 60%
A little less time expended in later iterations.
8%
Resources
Effort 24%
Effort 8%
Inception
– 20%
Elaboration
– 33%
Construction
– 40%
Transition
– 7%
Time
Source: Unified Software Development Process pages 335, 336
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
12
Projects With A Fixed Team Size
With this, can see that the Inception and Elaboration Phases we are typically overstaffed
(people idle while vision, technical architecture, etc. are identified) OR (if not overstaffed)
Construction phase is extended delaying delivery.
Project will more likely be successful when we can add the right people at the right time.
Too many people at wrong time causes overhead and confusion before project can really
use these people; adds also to cost; they want to do something, but have no direction
Resources
10 %
Effort 20%
Effort 60%
10%
Inception
– 10%
Time
Elaboration
– 20%
Construction
– 60%
Transition
– 10%
With a fixed size team effort and duration converge
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
13
Iteration Duration and Frequency
•
•
•
•
Start an iteration: have a rough set of goals.
Within iteration: do the scenario realization
End of iteration: assess results; deliver executable.
 Because this is the typical pattern, it is good to agree
on a common iteration schedule.
•
•
•
•
So, How Quickly Can a Project Iterate? Consider:
Need a day or two for iteration startup (planning)
Need a day or two for closedown (post mortem reviews).
Iteration duration lasts between two and six weeks. But,
of course, there are exceptions – and there are many.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
14
How Quickly Can You Iterate?
• Iteration Length - Typically 2-6 weeks
– Low 1 week
– Most common 4 weeks (30 calendar days)
– High 10 weeks
• Size varies by:
–
–
–
–
–
–
–
Team size
Objective
Amount of overhead
Team distribution and availability
Project formality
External dependencies
Project environment
• Let’s look at these a little more closely
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
15
Project Iteration – Factors – Great Slide!
•
Team Size:
–
•
•
Larger teams have more overhead  longer iterations.
• Generally: 2 to 15 people: 2 to 4-week iterations
• 15-30 people – 4 to 6-week iterations
• 30-50 people – 6 to 8 week iterations.
Iteration’s Objectives – sometimes these simply require more time.
Amount of Overhead –
• The more meetings and admin overhead required by the owning organization, the
longer the iterations will be.
•
Team Distribution –
• The more distributed the team, the longer to agree on decisions and hence the
longer the iteration; More communications will be needed too.
•
Resource Availability –
• The amount of dedicated time definitely impacts iteration length. Dedicated
workers lessen the length and conversely.
•
Project Formality –
• Some projects have stringent reviews / project documentation.
– This requires more time to deliver, coordinate, buy-in, etc. these items.
•
External Dependencies –
• Dependent on external suppliers and resources? Add time.
• Iterations are difficult to plan and control.
• Regulatory agencies, partners can influence duration
•
Project Environment –
• Agile and dynamic environments require a special environment.
• Facilities must be in place for development and communications.
– Meeting rooms, quiet areas, etc.)
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
16
Notes on Duration of Project Iterations:
• No ‘one size fits all’ here…
• Iteration size needs to vary depending on project risk, how
much work is to be done, and available resources and
really, a host of other factors.
• Generally good to start with a length of four to six weeks
and adjust rather quickly based on initial experiences.
• A four-week iteration (measured in working days) might
well span six weeks.
– So be careful and recognize holidays, vacations, etc.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
17
How Many Iterations in an Evolution?
Interesting…but there is wide variability in these: ahead.
Total
Inception
Elaboration
Construction
Transition
1
1
Small
3
1
Typical
6
1
2
2
1
Large
10
2
2
4
2
A project may have many more iterations (20 to 40 have
been reported) but would go through many cycles.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
18
Again: note the well
regarded people have different takes:
• Walker Royce – 4 to 9 iterations.
– Typical 6: 1, 2, 2, 1; Small 4: 1,1, 2, 1. Large 9: 2, 2, 4, 1
•
•
•
•
Krutchen suggests 3 to 10 iterations
RUP suggests 3 to10 iterations, typically 6 to 8
Larman: 3 to 45. Two year project 20 iterations.
Bittner and Spence offer that 10 iterations is considered
quite large for a single evolution.
– Ten iterations implies either there is a long time before the end of
Construction when the evolution is initially deployed or there are a
lot of iterations in the Transition phase, each deploying a minor
upgrade to the system and a long time to wait before any major
changes can be made.
– Bittner and Spence also suggest ten iterations should take no
longer than nine months to ensure business value is delivered
within a typical business budgeting cycle.
– This position implies difficulty if evolution is more than 10 iterations.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
19
A Strange Coincidence: The Square Root Rule
Iterations
Project Duration
Length
Number
Two years
100 weeks
10 weeks
10
One year
49 weeks
7 weeks
7
Nine months
36 weeks
6 weeks
6
Six months
25 weeks
5 weeks
5
Four months
16 weeks
4 weeks
4
Two months
9 weeks
3 weeks
3
One month
4 weeks
2 weeks
2
As with the other figures presented, these are intended for background information and guidance only.
Key consideration in determining length of release cycle, size and number of iterations within
this cycle should always be the specific needs, risks and constraints of individual project.
The probable underlying cause of the above correlation is that longer projects tend to be larger
projects with relatively large teams, and it is harder to iterate quickly with a large project team.
Source: What if we used common sense?, J Marasco, Rational Edge, Jan 02
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
20
Forces That Extend Phases
We know that phases do not have a fixed duration; they take as long as needed to mitigate
risks they are responsible for. So, consider some factors that may extend risk:
Phase
Inception
Elaboration
Construction
Transition
© 2005 Ivar Jacobson International
Force
Highly volatile scope
Unknown business environment
Stakeholder disagreement
Unproven architecture
Unstable requirements
Unstable development environment
Challenging non-functional requirements
No deployment window
Large amounts of functionality to produce and test
Poor architecture
Inability to scale up the development team
Poor quality
Hardware / system distribution and replacement
Level and length of support required
Iterative Project Management / 04 - Phase Planning and Assessment
21
Staying on Schedule
• But most projects have some sort of fixed deadlines
– Based on market needs, regulatory needs, management
directives, and other overall desired outcomes.
• So, what to do?
• Two Choices:
– Reduce Scope or
– Add Resources.
• Fred Brooks (we have discussed) said adding resources
to a late project will make it later. 
• But we have found that
(Fixed Scope) + (Fixed Duration) = Failure
So decisions must be made reconciling the features
delivered against the risks incurred to complete on time
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
22
The Good News and Reality Check:
• Yes, there is good news:
• Reality is that not all requirements have equal import.
• Can usually identify a set of requirements than can be scrubbed or
moved to a later evolution assuming there is an atmosphere of
cooperation and aligned goals between the business and the
development team.
• Authors point out that more than one project has failed for forcing an ‘all
or nothing attitude’ regarding project scope.
• The reality is simple.
• When unknown risks raise their ugly heads, if we do not reduce scope
or extend the schedule, failure is imminent.
• Project manager must intestinal fortitude to state the truth if necessary.
– By not doing so, the results are significantly worsened!
• If I may quote: “Ignoring project risk is like ignoring a potentially
terminal disease that can be treated if caught early but that becomes
increasingly lethal the longer the symptoms are ignored.”
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
23