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 InceptionElaboration WBS ElementsFidelity ManagementHigh EnvironmentModerate EnvironmentHigh RequirementsHigh RequirementHigh DesignModerate DesignHigh ImplementationLow ImplementationModerate AssessmentLow AssessmentModerate DeploymentLow Fidelity WBS ElementsFidelity WBS Elements Fidelity WBS ElementsFidelity ManagementHighManagementHigh EnvironmentHighEnvironmentHigh RequirementLowRequirementLow DesignLowDesignModerate ImplementationModerateImplementationHigh AssessmentHighAssessmentHigh DeploymentHighDeploymentModerate TransitionConstruction

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 ElementsDefault Budget Management10% Environment10% Requirements10% Design15% Implementation25% Assessment25% 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 DomainInceptionElaborationConstructionTransition Effort 5%20%65%10% Schedule10%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