Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
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 issuesConventional WBS frequently suffer from
three fundamental flaws
They are prematurely structured around the product designThey are prematurely decomposed, planned & budgeted in either too much or to little detailThey are project-specific, and cross-project comparisons are usually difficult or impossible
Work breakdown sructuresEvolution 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 structureEvolution of planning fidelity in the WBS over the Life Cycle
Inception ElaborationWBS Elements Fidelity WBS Elements Fidelity
Management High Management HighEnvironment Moderate Environment High
Requirements High Requirement HighDesign Moderate Design HighImplementation Low Implementation ModerateAssessment Low Assessment ModerateDeployment Low Deployment Low
WBS Elements FidelityFidelity WBS ElementsWBS Elements FidelityFidelityManagementManagement HighHigh ManagementManagement HighHighEnvironmentEnvironment HighHigh EnvironmentEnvironment HighHighRequirementRequirement LowLow RequirementRequirement LowLowDesignDesign LowLow DesignDesign ModerateModerateImplementationImplementation ModerateModerate ImplementationImplementation HighHighAssessmentAssessment HighHigh AssessmentAssessment HighHighDeploymentDeployment HighHigh DeploymentDeployment ModerateModerate
TransitionTransition ConstructionConstruction
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 Default Budget
Management 10%Environment 10%Requirements 10%Design 15%Implementation 25%Assessment 25%
Deployment 5%
Total 100% Cont.
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 TechniqueBottom-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
ElaborationMost 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
ConstructionMost 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
TransitionMost 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
