Iterative Project Management

Iterative Project Management Chapter 3 - Controlling an Iterative Project Modified considerably by Instructor Two Classes

Objectives – Major sections: • Introductory Remarks • Variables that Shape Projects • Scope; time; cost; quality • Stakeholders – the Real Drivers of project success • Controlling the Project as a Whole • The Unified Process Phases Iterative Project Management / 02 - Controlling an Iterative Project

0. Introductory Remarks • Big point behind iterative development is this approach provides for • enabling stakeholders to evaluate progress, replan, if necessary, and • empowering management to take full control over projects maximizing the chances of success. • Managing iterative projects is challenging because all of the disciplines: project management, requirements, analysis, design, implementation, and test are interleaved such that there are no real clear cut boundaries from one to the other. • Very different from methodologies from the past that are still in large part subscribed to… • This perceived inability to plan in accustomed ways can cause some to ‘retreat’ to waterfall style while citing this as proof that iterative approaches do not work • Just like any other approach, we need training and practice. Iterative Project Management / 02 - Controlling an Iterative Project

Introductory remarks – 2 • Again, dividing a project into iterations • provides much greater control over the project because it allows us to: • explicitlymanagerisk within each iteration, and • force each iteration to produce something tangible that can be tracked, quantified, and reported to senior management. • Each iteration removesdifferent risks in a planned manner and not haphazardly. • The key is: knowing exactly what to do and when to do it, and how much of each discipline we need to employ in an iteration, and how to assess progress. • Lets look at essentialvariables crucial to planning these iterations. Iterative Project Management / 02 - Controlling an Iterative Project

Variables that Shape Projects: • Key variables presented in most management books include: • Scope, cost, and time, or • Quality, cost, and time • Our approach is to employ all four in a not-so-rigid ‘square.’ • First: look at the metrics (parameters) scope, quality, cost and time. Iterative Project Management / 02 - Controlling an Iterative Project

Key variables – scope, quality, cost, and time • Scope: • All develop efforts have lists of requirements or features that need to be cranked into the application (new or redesigned into…) • Generally speaking, this is the number of requirements (usually in terms of features or functions) that the software must accommodate. • These can be captured in may ways some of which we have discussed. (More ahead on this) • Every project has scope. • Quality: • Usually quantified in terms like MTBF, MTTR – as used in real-timesystems and other engineering / manufacturing / similar systems. • Not used very much for information systems… • A sometimes used metric is defects/thousand lines of code • Can be very misleading… • Just because there is a small number of defects does NOT mean that the code is of high quality: • Better: fitness for purpose – measured in terms of the relative priority of the implemented features and the number of them that were actually required. • Sometimes number of ‘incident reports’ or ‘deficiency reports…’ Iterative Project Management / 02 - Controlling an Iterative Project

Key variables – scope, quality, cost, and time • Cost: • Usually termed, ‘resources.’ • Single most significant aspect of a software development’s project cost. • People, equipment, training, customer service, travel, development / management support… • Time: • Time taken to complete the project – usually stated in terms of some market driven goal of having the solution to market by some specific day • Often measure in man-hours/ man-days / man-years… • Remember, people and time are NOT interchangeable!! Iterative Project Management / 02 - Controlling an Iterative Project

Additional comments: • Important to note variables are notmutuallyindependent • They form the basis of visuals or other ‘mechanisms’ such as time box, scope box and others to be discussed. • Changes in time may well affect other parameters; certainly changes in scope may well do the same. • Changes in one of these parameters must be compatible with the others – and may well not be. • These four parameters must be compatible, attainable, and supported by stakeholder’s ‘shared’ understanding of the project’s success. • (Remember, ‘Take no small slip!’ – Frederick Brooks, The Mythical Man Month. Iterative Project Management / 02 - Controlling an Iterative Project

II Stakeholders: the real drivers of project success • Must realize the stakeholders that drive the project. • But there are several categories of ‘stakeholders.’ • They are the primary sources of requirements, constraints, and risks, funding and much of and often ultimate decision making. • May ‘classify’ stakeholders by ‘domain:’ • The Problem – those affected by the problem(s) the project will solve. • They are the primarysources of requirements; • They will ‘confirm’ when problem solved and accept solution. • The Solution – those affected by solution because they must support the operation or change their jobs. • Might not directly benefit from the solution. • The Project – group responsible for delivering the solution to other stakeholders Iterative Project Management / 02 - Controlling an Iterative Project

We constantly need to prove to these stakeholders that real progress is being made. • GREAT QUESTION: • HOW DO WE DO THIS? • HOW DO WE ASSUAGE THEIR FEARS? • HOW DO WE INSTILL CONFIDENCE IN THE PROCESS? • All we do is directed toward these ends. Iterative Project Management / 02 - Controlling an Iterative Project

III Controlling Individual Iterations – Key Parameters • All iterations have • a beginning, middle, and end along with • goals and successcriteria used to assess performance. • First and foremost, we must controlthe iterations in order to control the overall project. • Our approach: ‘fix’ two of the classic control variables and varythe other two • We will fix time – by creating a ‘time box’ and • We will fix scope – by defining exactly what will be delivered in the iteration. • We will then consider controlling iterations using a time box or a scope box and discuss the relative merits (or demerits) of each. Iterative Project Management / 02 - Controlling an Iterative Project

Time Boxing • Idea here is to divide project into a series of equal length time boxes. • Except for some initial time boxes, which may require a little learning to lock in a good ‘period,’ these should be fixed and remain fixed at all costs! • Time boxes are the sacred cow of an iterative process. • are the building blocks / framework of successful iterations! • provide for a pause, synchronization point for progress of all kinds • Time is fixed and scope becomes the control variable • Cost varies with time and scope • Quality is considered as a secondary control variable. • For a specific iteration, we identify the requirements (scope – in terms of scenarios) whose implementation may be used to determine success. • We set a quality level desired and costs are usually controlled by number of people working during this iteration. Iterative Project Management / 02 - Controlling an Iterative Project

Iterations: Time Boxes or Scope Boxes Time is the fixed component of the project plan; functionality becomes the variable. Time boxing is recommended approach for controlled iterative and incremental development. • Scope Box – A fixed set of requirements delivered in the timeneeded to realise them to an agreed level of quality. • Time Box – As many requirements as can be realized in a fixed amount of time with a given amount of resources. (the desired amount of quality factors in…) Scope Quality Resources Time Scope Quality Resources Time Iterative Project Management / 02 - Controlling an Iterative Project

Recommendation: Time Box The Iterations Resources Iteration 1 Iteration 2 Iteration 3 Deliver Start Deliver Start Deliver Start Note: Time is fixed, resources may vary. But the resources are normally fixed for an iteration: An appropriate amount of work - based on priorities of requirements / effort - is determined. Time The start and end points of each iteration are fixed. Effort available is governed by the size and skill of the team. Iterative Project Management / 02 - Controlling an Iterative Project

Fitting the Work (Scope) Into the Time Box Requirement 1 Requirement 2 Overhead We map an appropriate amount of work onto the time box (iteration). Scope is thus established by selecting requirements, changes, defects, starting with highest priority items and working down to lesser ones. Ideally, they are of approximately equal effort. This approach greatly simplifies the planning process. (Much more later…) Iterative Project Management / 02 - Controlling an Iterative Project

Adjust The Plans (not time boxes) Based On Project Results • Each iteration is assessed and the feedback generated used to adjust the project plan. May be shortfalls moved to later iterations. • Do not change the length of the time box! • Since we address most significant items first (risk, functionality) If we come up short, it should be for those ‘lesser’ items. • Can always move items from later iterations to current one, if... ThisTime Box LastTime Box Future plans are adjusted in the light of lessons learned from the current iteration. Feedback used to adjust the project plan Iterative Project Management / 02 - Controlling an Iterative Project

Caution on Roll Back… • It is important that the impact of moving work back is assessed for the project as a whole, and that the project does not succumb to the snow-plow effect. • This may occur when all the work gets pushed back, iteration by iteration, and we end up in the situation where the last iteration is expected to deliver its originally planned functionality plus all of the left over work from the preceding iterations. Iterative Project Management / 02 - Controlling an Iterative Project

Adjusting time boxesif we come up short??? • Seems like this is reasonable, but…if we do: • Box boundaries become meaningless • Once we slip, we will likely slip more rather than catch up. • Must ‘close out’ the iteration and learn. Domino effect…. • Time boxes establish a sense of urgency; a rhythm; pulse. • We are aware of project constraints and we need to be! • As a heuristic, develop the most important requirements first – so that if you come up short, lesser requirements drop out. • It is indeed tempting to stretch the iteration just a wee bit. But: • Extending implies all is going well – must be realistic and honest! • It is not disruptive to stop and pause and adjust the next iteration. • Don’t want to appear we are failing to achieve objectives. • Perhaps original objectives were too aggressive. Recognize these. Iterative Project Management / 02 - Controlling an Iterative Project

Treat The Time Box As Sacred If all the work is done move some forward from the next iteration rather than shrink the time box. If there is too much work move some to the next iteration rather than extend the time box. Rather than change the current time box, work is moved around between the iterations. Iterative Project Management / 02 - Controlling an Iterative Project

Beware of Slipping!!!! • The authorscite that they can all think of circumstances where it might be beneficial to extend an iteration’s time box to allow the team to successfully fulfill the iteration’s objectives • But, as a general ‘rule-of-thumb’ this should be avoided. • An extension should only be considered as an appropriate action once the iteration has been concluded at the end of the original time box. • This may be one form of adjusting the project plans. • They cite clearly that once things start to slip they are more likely to slip some more rather than conclude the iteration, especially if we do not take the time to • close out the iteration and • learn the lessons from its execution. Iterative Project Management / 02 - Controlling an Iterative Project

Heuristics for controlling iterative projects w/time boxes: • Estimate and prioritize work to be done • Address highest priority items first • Assess iterations and actupon lessons learned • Measureperformance and progress in each iteration • Adjust priorities and scope based on results. • Time boxing, remember, is (among other things) used • as a managementtool used to gauge project progress. • To provide regular inputs to stakeholders as to the progress of the project. • To facilitate predictability resulting from successful iterations helps in the planning and understanding of stakeholder involvement. • To assure all stakeholders that the project is on track. Iterative Project Management / 02 - Controlling an Iterative Project

Second Night on this set of Slides Iterative Project Management / 02 - Controlling an Iterative Project

Scope Boxing • Here: we have specificsetsofrequirements /iteration. • ‘Scope’ drives the iteration • (the more functionality we include in the scope box, the more must be completed to meet the objectives of the iteration). • D1: Scoping gives rise to iterations of unequal duration. • D2: This stops fixedperiods of evaluation and • D3: This stops the use of time as a control mechanism. • Many have adopted this approach but it is not truly iterative and incremental and does not really control project scope, schedule, and effort. Why NOT??? • Without regard to fixed time limits, this can be very dangerous. • Requirements are not moved, instead iterationlength is extended • Absence of hard time constraints may obviate the sense of urgency for getting work done. • Lack of deadlines hurts keeping project on track. Iterative Project Management / 02 - Controlling an Iterative Project

Scope Boxing • Additional problems • When do you adjust project plan as a result of learning in a scope box? • What do you do if the scope box is overrunning? • What do you use as intermediate milestones? • Under what circumstances can you draw the scope box to a close before it is completed? • When do you pause and learn from lessons learned from scoping? • Progress is now irregular and unpredictable – How so? • No opportunity for feedback before work is ‘done’ Agree? • Fewer opportunities of some stakeholders to provide early inputs – Agree? How so? • Can be a lack of motivation and hence a lack of direction. Iterative Project Management / 02 - Controlling an Iterative Project

Authors’ recommendations (1 of 2): • Guidelines for controlling iterations: • 1 Every iteration should be treated as a discrete time box • 2; Iterations should be defined by their intendedresults and the evaluation criteria for these results • 3. Every iteration should actively address and reduce project risk • 4. During an iteration, the project team members should focus on meeting the objectives of the iteration alone and doing whatever they can to ensure the iteration’s success and no more. Iterative Project Management / 02 - Controlling an Iterative Project

Authors’ recommendations (2 of 2): • 5. Every iteration should produce an executable release. The release should fulfill more the the project’s requirements than the previous release (from the previous iterations) (incremental advancement of business value!) • 6 Every iteration should endontime Don’t change date/time • 7. At the end of the iteration, its results should be objectivelyassessed; the team should be prepared to rework the solution and project plan as required. We still do not have enough detail here to plan iterations. Need more to be able to discuss how to decide what project risks should be addressed first and whatrequirementsshouldbeimplemented in which iteration. Iterative Project Management / 02 - Controlling an Iterative Project

IV Controlling the Project as a Whole • We clearly need some kind of overarching controlframework within which the project can iterate • Cannot simply have a set of iterations…. • Time boxed or otherwise…. • Need a framework to address certain risks / functionalities first. • Need some kind of lifecycle ‘anchors’ or ‘milestones’ through which we can check out the ‘state’ of the project. Iterative Project Management / 02 - Controlling an Iterative Project

Lifecycle Anchor Points – Technical Milestones • Look to three anchor points between project start-up and close-down • Lifecycle Objectives (LCO) • Project Viability Agreed; Conclusive proof; • Technical and Financial feasibility. • Understand scope and risks that threatened completion • Have a credible plan and architecture in place. • Lifecycle Architecture (LCA) • Selected technical approach - proven and stable. • Architectural model solid; agreed to; workable. • Execute a partial solution indicating solution works… • LCO and LCA measure the state of the project as a whole. • Focus is not on requirements snapshots or architecture-point solutions. • Rather, focus is on requirements and architectural specifications which anticipate and accommodate systems evolution. • Hence: ‘Lifecycle Objectives and Architectural Milestones.’ • Do these look familiar??? Iterative Project Management / 02 - Controlling an Iterative Project

Lifecycle Anchor Points – Technical Milestones - more According to your authors: • Stakeholder concurrence on the milestone elements is essential. • Establishes mutualstakeholder buy-in to the plans and specifications; • Enables a collaborative team approach to unanticipated setbacks rather than an adversarial approach as in most contract models. • Consideration of the business case at these milestones (anchor points) is an essential rather than an optional add-in • As Barry Boehm likes to say “The LCO milestone is the equivalent of getting engaged, the LCA of getting married. As in life, if you marry your architecture in haste, you and your stakeholders will repent at leisure. The third anchor point milestone, the initial operationalcapability (IOC) represents an even bigger commitment: It is the equivalent of having your first child.” • So, on to the Initial Operational Capability: Iterative Project Management / 02 - Controlling an Iterative Project

Initial Operational Capability (IOC) • Usable Solution Available to user community in prerelease form • Here, we must have a working product that users are prepared to receive • Look familiar? When does this occur? • Is application ready for deployment? • Has it been beta tested? Acceptance tested? Etc.???? • A number of pioneers has established such a framework – notably Jacobson, Booch, Rumbaugh, Krutchen, and Walker Royce. • OK. Here we go: Iterative Project Management / 02 - Controlling an Iterative Project

The Unified Process as a Management Framework Each phase in the software development life cycle (sequential) ends in the achievement of a major milestone for planning and control. Business Modeling Configuration and Control Iterative Project Management / 02 - Controlling an Iterative Project

The Need For Milestones (from book…) • Phases provide way to focus on specifickinds of risk. • Each phase addresses critical risks that must be mitigated. • Must have mitigated risk at end of each phase to move on. • Two types of milestones to be addressed in these phases: • Business Milestones • Anchor the project with business commitments • What does this mean to you? DISCUSS! • The project must be synchronized, and in-line with the business • TechnicalMilestones • Anchor the project against the overall system lifecycle • Provide a framework for directing the iterations and their plans. Iterative Project Management / 02 - Controlling an Iterative Project

Phases and their Purpose Phases: an objective measure of the ‘state’ of the project. The phases define a risk-driven lifecycle We will discuss these risks in much more detail ahead. But, you should recognize the risks in focus for each of the phases! Iterative Project Management / 02 - Controlling an Iterative Project

Why do we have these Phases and Milestones? • These periods are very important. • Can focus on the project as a whole and one might be able to simply say that the project is now is x phase. • Milestone ‘gates’ serve many purposes: • Provide concrete evidence of progress for the decision makers • Can monitor project at key points • We resynchronize stakeholder expectations, and decisions made/not made to continue. • Milestones in the UP used to measure state of the project as a whole! • Looking at risk reduction and on establishing key principles that anticipate and accommodate systems evolution. • Stakeholder buy-in with each milestone is essential! •  So, in summary, the UP milestones serve as:  • Commitment points and progress checkpoints • System-wide events that synchronize the whole team, and • Measure of the state of the project. Iterative Project Management / 02 - Controlling an Iterative Project

Phases versus Iterations • “Phases and process milestones [in the UP] are defined by the process and are common to all projects. • “The number and size of the iterations and their specificobjectives are at discretion of the project manager and development team. • End of phase milestones represent ‘toll gates” that cannotbepassed without achieving specific results. • Phases are not time boxes in the same way iterations are. •  Iterations are concluded when the time runs out; •  Phases are only concluded when their objectiveshavebeen met.” • Phases consist of one or more iterations the completion of which is a minormilestone. • Phases end with a go / no-go decision. Major Milestones. Iterative Project Management / 02 - Controlling an Iterative Project

Iterative Project Management