Iterative process
planning
Overview
Introductory Remarks
10.1 Work breakdown structure
10.2 Planning Guidelines
10.3 The cost & Schedule estimating
process
10.4 The iteration planning process
10.5 pragmatic planning
Introductory Remarks
Projects can underplan & they can overplan. Balance
is dominant in the level of planning details & buy-in
among stakeholders
Work breakdown structure is the “Architecture” of the
project plan. It must encapsulate change & evolve
with appropriate level of detail throughout the life
cycle
Cost & schedule budgets should be estimated using
macro analysis techniques( Top-down project level )
& microanalysis ( Bottom-up task level ) to achieve
predictable results
Work breakdown sructures
A WBS is simply hierarchy of elements that
decomposes the project plan into discrete work tasks
A WBS provides the following information structure
A delineation( description, definition ) of all significant
work
A clear task decomposition for assignment of
responsibilities
A framework for scheduling,budgeting & expenditure
tracking
Work breakdown sructures
Conventional WBS issues
Conventional WBS frequently suffer from
three fundamental flaws
They are prematurely structured around the product
design
They are prematurely decomposed, planned &
budgeted in either too much or to little detail
They are project-specific, and cross-project
comparisons are usually difficult or impossible
Work breakdown sructures
Evolution Work breakdown structures
An evolutionary WBS will organize the planning elements around
the process framework( Workflows, Phases & artifacts ).
This approach accommodates the expected changes in the
evolving plan
The basic recommendation for the WBS is to organize the
hierarchy as follows
First-level WBS elements are the workflows.These elements are allocated to a
single team & constitute the anatomy of a project for the purpose of planning &
comparison with other projects
Second level elements are defined for each phase of life cycle. These elements
allow the fidelity (reliability, commitment )of the plan to evolve more naturally
with the level of understanding of the requirements, architecture & the risks
Third-level elements are defined for the focus of activities that produce the
artifacts for each phase.These elements may be the lowest level in the hierarchy
that collects the cost of a discrete artifacts for a given phase
Work breakdown structure
Evolution of planning fidelity in the WBS over the Life Cycle
Inception
WBS Elements
Fidelity
Management
Environment
Requirements
Design
Implementation
Assessment
Deployment
High
Moderate
High
Moderate
Low
Low
Low
WBS Elements
Management
Environment
Requirement
Design
Implementation
Assessment
Deployment
Fidelity
High
High
Low
Low
Moderate
High
High
Transition
Elaboration
WBS Elements
Fidelity
Management
Environment
Requirement
Design
Implementation
Assessment
Deployment
High
High
High
High
Moderate
Moderate
Low
WBS Elements
Management
Environment
Requirement
Design
Implementation
Assessment
Deployment
Fidelity
High
High
Low
Moderate
High
High
Moderate
Construction
Planning Guidelines
Two simple planning guidelines should be considered when a
project plan is being initiated or assessed
The first guideline prescribes a default allocation of costs among first-level
WBS elements
First-Level WBS Elements
Management
Environment
Requirements
Design
Implementation
Assessment
Deployment
Total
Default Budget
10%
10%
10%
15%
25%
25%
5%
100%
Planning Guidelines
The first Guideline provides default allocations for budgeted
costs of each first-level WBS element.These values are vary from projects
which provides a good benchmark for assessing the plan. This provides
cost allocation but not effort allocation. To avoid misinterpretations two
explanations are necessary
The cost of different labor categories is inherit in these numbers
The cost of hardware & software assets that support the process
automation & development teams is also included in the environment
element
Planning Guidelines
The Second guideline prescribes the allocation of effort & schedule across
Life-cycle phases
Default distribution of effort & schedule by phase
Domain
Inception
Elaboration
Construction
Transition
Effort
5%
20%
65%
10%
Schedule
10%
30%
50%
10%
These values vary depending on the specific constraints
of an application, they provide an average expectation across a
Spectrum of application domains
The cost & schedule
estimating process
Project plans need to be derived from two
perspectives
macro analysis technique
Top-down project level
micro analysis technique
Bottom-up task level
The cost & schedule
estimating process
Macro Analysis Technique
Top-down approach ( Forward-Looking )starts with an understanding of general
requirements & constraints then decomposes these elements into lower level budgets &
intermediate milestones
The following planning would occur
The software project manager & others develop a characterization of the overall size,
process, environment, people & quality required for the project
A macro-level estimate of the total effort & schedule is developed using a software cost
estimation model
The software project manager partitions the estimates for the effort into a top-level WBS
using guidelines
At this point, subproject managers are given the responsibility for decomposing each of
WBS elements into lower levels using top-level allocation,staffing profile & major
milestone dates as constraints.
Top-down approach is dominate at Engineering stage
The cost & schedule
estimating process
Micro Analysis Technique
Bottom-up approach ( Backward-looking ) starts with analyzing the
micro-level budgets & schedule then sum all these elements into higher level
budgets & intermediate milestones
The following planning would occur
The lowest level WBS elements are elaborated into detailed tasks,for which
budget & schedule are estimated by the responsible WBS element manager
Estimates are combined & integrated into higher level budgets & milestones
Comparisons are made with the top-down budgets & schedule milestones.
Gross difference are assessed & adjustments are made in order to coverage
on agreement between top-down & bottom-up estimation
Bottom-up approach is dominate at production stage
The Iteration Planning Process
The iterations of the project will be
Inception
Large-scale,custom developments may require two iterations to achieve an
acceptable prototype but most project should be able to get by only one iteration
Elaboration
Most projects should plan on two iterations to achieve an acceptable architecture
baseline.
Unprecedented architecture may require additional iterations whereas
projects built on well-established architecture framework can probably get by with a single
iteration
Construction
Most projects need at least two construction iterations there are many reasons to
add one or two more in order to manage risks or optimize resource expenditures
Transition
Most projects learn to live with a single iteration between a beta release &
final product release
The Iteration Planning Process
The general guidelines is that most projects will be between
four & nine iterations. The Typical project would have the following
six-iteration profile.
One iteration in Inception : an architecture prototype
Two iterations in Elaboration: Architecture prototype & architecture
baseline
Two iterations in Construction : Alpha & Beta release
One iteration in Transition : Product release
Highly precedented projects with a predefined architecture or very small-scale
projects could get away with a single iteration in a combined inception & elaboration
phase & could produce a product efficiently with the overhead of only four iterations
A very large or unprecedented project with many stakeholders may require an
additional inception iteration & two additional iterations in construction for a total of nine
iterations
Pragmatic Planning
Even though good planning is more dynamic in an iterative process, doing it accurately
is far easier.
While executing iteration N of any phase, the software project manager must be
monitoring & controlling against a plan that was initiated in iteration N – 1 & must be
planning iteration N + 1.
The art of good project management is to make trade-offs in the current iteration plan &
the next iteration plan based on objective results in the current iteration & previous
iterations.
Bad architectures & misunderstood requirements, inadequate planning is one of the
reasons for project failure conversely the success of every successful project can be
attributed in the part of good planning.
For any project planning document is not important but act of planning is extremely
important to project success which provides a framework & forcing functions.
Pragmatic Planning
Plans are not just for managers. The more open & visible the planning process & results
the more ownership among the team members who need to execute it.
Bad, closely held plans cause attrition. Good ,open plans can shape cultures &
encourage teamwork