Iterative Project Management Lifecycle Planning Chapter 5 A

Iterative Project Management Lifecycle Planning Chapter 5 – A Layered Approach to Planning and Managing Iterative Projects Modified considerably by your Instructor 1

Objectives • Understand why iterative planning is different • Understand how iterations and the unified process phases fit in with lifecycle and external release planning • Understand how iteration plans integrate with business plans © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 2

• Two prongs here: – Management and then – Planning. © 2005 Ivar Jacobson International 3

Layered Approach to Planning and Managing Iterative Projects. • Plans need to be simple. Pure fact! • The more detailed a plan is, the less accurate it becomes. • Certainly a very detailed plan will be more likely to require changing! – As plans ‘slip’ the slippage dominos down the line invalidating so very much carefully-undertaken planning. • Bear in mind that Waterfall and other heavy-weight processes are said to be: “plan driven. ” – Mathematically it can be readily shown that as the number of tasks in a plan increases, the probability of it remaining accurate becomes increasingly unlikely. © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 4

For that matter: Why plan at all? 1. Planning forces considerations of possible outcomes and responses to those outcomes 2. Planning is necessary to coordinate the work of independent resources. 3. We need key evaluation points in order to ensure project is going well and also to align work efforts. “If you don’t know where you’re going, any path will get you there!” © 2005 Ivar Jacobson International 5

Solution to Detailed Planning is ‘Layering. ’ • Successive hierarchical layering refines plans to more detailed levels. • And, layering also limits the extent to which change can ripple through the best made plans since each layer exists at different levels of abstraction… • The nice thing about a layered approach to planning is that at any level of abstraction, if we need more detail, go down one level. But the plan at any one level is complete and appropriate for the ‘concerns’ at that level. Will now look at management layers that support and enable successful iterative projects, © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 6

The Management Layers • Management Layers are not imposed bureaucracy. • Rather, they are “separation of concerns. ” • The ‘concerns’ at one layer should not be the concerns of another layer, although layers certainly influence other layers. • Management Layers: – Organizational-Program Management (note: ‘Program’) • Deals with business strategy and vision. • Sets business context for one or more projects – Overall Project Management – (note ‘Project’) – Here, this layer is concerned with directing and managing a specific project – overall planning, monitoring, and control of the project; coordinates development and delivery of one or more products. – Day to day Development Management – (note ‘Development’) – deals with the overseeing of delivery of development work and ensuring the quality of products released. © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 7

Higher versus Lower Levels of Management • Higher levels control lower levels – Provide funding and support – Develop project ‘charters’, etc. • Lower level outputs provide inputs to higher levels – very necessary for them to properly function. – Lower levels absolutely must provide evidence to program management that all is on track and that the project is delivering value. © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 8

Planning at Multiple Levels The program management layer is present in a lot of modern businesses. Where the projects are not parts of program then the organization’s ‘Strategic Management” plays the same role. Notion of a Program Management Level is common (PMO) Program Management (Benefits Realization) Overall Project Management (Benefits) Software Development (External Releases) It 1 It 2 It 3 It 4 …… It N-1 It N An iterative development practices layer is shown because iterations are used to evolve the products to be delivered by the development layer. Typically these layers are run concurrently too. Adapted from Implementing RUP Within a PRINCE 2 Environment: Laurence Archer, Oak IT, 2001 © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 9

Let’s look at these layers of management: Let’s look at these Management layers © 2005 Ivar Jacobson International 10

Program Management Layer • Emphasis: the Organization. – Please ‘to note’ the emphasis on ‘program. ’ – Provides oversight to ensure constituent projects provide • value to the organization and are • aligned with business needs. – In this layer, concerns do not center on a specific project; rather the overall value of all ‘solutions’ to the organization. – This layer is concerned with • investment expenditures, • delivery schedule, and • any interfacing / coordination with other projects. © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 11

Overall Project Management Layer • Emphasis: the Project! – Here we emphasize the project – a specific time to deliver (end of project) given resources – The overall project management plan is a high-level design and does not legislate ‘how’ the details are carried out. – Project manager is responsible for • using resources to • deliver desired business benefit. • Is responsible for effective utilization of resources needed to deliver desired business value within a time frame. • overall project risks and benefits, and resources. – Does not deal with the day-to-day details of the project – Ensures project is on track and will achieve desired results. © 2005 Ivar Jacobson International 12

Development Layer • Emphasis: the focus on Major Releases. (end of Transition) • Focus on definition, evolution, and delivery of major releases of the products required by the overall project. – Note: we are saying ‘major releases’ not major milestones… • Layer coordinates resources across deliveries with overall project oversight and funding in mind. • Focus is internally directed on delivering deployable releases of software products. • Focus of overall plan was externally directed with its emphasis on delivering business value back to the business and the program layer. © 2005 Ivar Jacobson International 13

Iteration Layer • Emphasis: Focus is on the Iteration • Ensure the evolution of the required software products is undertaken incrementally in a controlled and managed fashion that actively reduces risk facing the overall project. • Real work gets done here • Each iteration focuses on incrementally evolving a software product. • A series of iterations is required to develop a major release that can be successfully deployed. • Since iterations focus on resolving specific risks at specific points in the project, they prevent risks from causing instability and by ensuring risk is addressed in an appropriate order – with the high-impact risks being addressed first. © 2005 Ivar Jacobson International 14

Role of Layers • Top three - present in all organizations developing software. • The fourth layer is added for teams using iterative approach. • Warning: there’s a natural tendency to merge development layer with overall layer. – But this implies a single major release, • This rarely happens as there is almost always at least one follow-on major release evolution. – It is strongly recommended to keep overall project management away from the developing management. • Well, at least a little bit… (see ahead) – Ensure benefits expected of each major release are aligned across the layers and communicated to the entire project team. © 2005 Ivar Jacobson International 15

• We’ve talked about the layers. • Now let’s talk about the plans…. © 2005 Ivar Jacobson International 16

These layers… • The layers themselves operate at different level of abstraction with a different time horizon • And this is good! – Lower the layer, shorter the time horizon and more detail, accuracy, and precise their plans need to be. – A ‘program plan’ may extend for years and be quite abstract whereas an iteration plan is highly focused, very precise, and short term. – These represent two ends of the spectrum of plans. © 2005 Ivar Jacobson International 17

Issues with Iterative Management and Senior Managers • Iterative project management normally focuses on lower two: – the development plan and – the iteration plan. • Senior managers need to be on board with iterative approach. – Here are the financial controls and oversight! – Many managers are not ‘sold’ on the virtues of iterative development. – Too often, iterative project management fails to convince senior managers. • Senior managers cringe at what they perceive to be loss of management control typified by agile processes • They may view these approaches as rebukes to management and that these approaches are in opposition to the visibility, etc. that they feel they need. – We absolutely need their support. © 2005 Ivar Jacobson International 18

Issues with Iterative Management and Senior Managers • This is very difficult for some, for in order to reduce risk and get better results, overall project managers need to delegate responsibilities and allow detail to be pushed down through the development layer and into the iteration layers where agile approaches are best implemented. • PM is steeped in traditional approaches that show themselves in their desire for detailed planning as the primary mechanism for risk reduction • But the nature of feedback provided by iterating at all levels will have effects far and beyond the development layer, and senior leadership needs to feel comfortable with this. • Fact is planning, monitoring, and control undertaken for an iterative project is different from that undertaken for a traditional project. © 2005 Ivar Jacobson International 19

Positioning the Unified Process Lifecycle • Will use the UP as our framework for controlling iterative development. • But note that each application of the UP is known as an evolution which results in a major release of the product. • Others may refer to an ‘evolution’ as a ‘cycle. ’ • To put this into perspective, it is important to note that very few software development projects deliver a complete solution in a single release. – Have a series of major, sequential releases; build on previous releases. – Each delivers major benefit to clients. © 2005 Ivar Jacobson International 20

Layering the Plans and Milestones • Planning effects a separation of concerns. • So we will exploit the management layers we’ve spoken about to provide for a simple set of plans: – one for each layer, – each focused on a different set of issues. • We need high level plans to look at the future. – Without these plans lower level efforts could be useless and without focus, even though the iterative approach enables us to do something concrete in each iteration. • Yet we need low level plans to get the work done – particularly in an iterative, agile fashion. © 2005 Ivar Jacobson International 21

© 2005 Ivar Jacobson International 22

Planning: a “Separation of Concerns. ” • This separation of concerns has a number of very important benefits. (Book) – Reduces management overhead and keeps plans and control mechanisms simple and focused – Keeps the detail focused on the short term where required. • We know that too much detail is counter productive on a longer term basis. – Provides plans with both breadth and depth required to satisfy all stakeholders in the project, and – Enables • managers to manage and • developers to develop. • What a concept! © 2005 Ivar Jacobson International 23

Overview of all three Plans: • • Overall project consists of development projects. Development projects are each an evolution of a product Each evolution is managed iteratively using the RUP lifecycle. Each UP phase consists of iterations, which in turn are made up of planned and executed activities. • • • Consider the next slide: There will be: One overall project plan for the project as a whole. One development plan for the current evolution. An iteration plan for the current iteration. As this iteration progresses and its results start to become apparent the planning of the next iteration starts. © 2005 Ivar Jacobson International 24

How Many Evolutions / External Releases? The reality is that very few projects deliver a single external release – One pass through the Unified Process lifecycle Inception Elaboration Construction Transition One evolution, deploying one major external release Most projects deliver the system in series of major external releases – Multiple passes through the lifecycle Evolution 1 Evolution 2 Evolution 3 Multiple evolutions, each deploying a major external release © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 25

How Many Plans Do You Need? This says it all. While there may be some variation, in general each plan can be (and probably should be) no longer than a few pages. The Overall Project Plan Evolution 1 Inception Development Plan Iteration Plan © 2005 Ivar Jacobson International Evolution 2 Elaboration Iteration 1 One for the current iteration plus, possibly, the outline of the next. Evolution 3 Construction Iteration 2 Transition Iteration 3 Task 1 Task 2 Task 3 Iterative Project Management / 03 - Lifecycle Planning 26

High Level Plans Focus On Achievements The Overall Project Evolution 1 Inception Evolution 2 Elaboration Evolution 3 Construction Transition We have a UP evolution for each major external release (Release 1, 2, 3 etc) During the transition of Release 1, fixes and emergency releases may be required (Releases 1. 1, 1. 2, 1. 3 etc). This is a very common occurrence! Iteration 1 These release numbers would be the result of undertaking Transition iterations as part of first evolution. © 2005 Ivar Jacobson International Iteration 2 Iteration 3 Task 1 Task 2 Task 3 Iterative Project Management / 03 - Lifecycle Planning 27

The Overall Project Plan • Each major project has a single, brief, overall project plan. • It should lay out the number of evolutions and anticipated major releases needed to provide the overall solution. • This plan will include – – milestone dates, functionality delivered, risks to be addressed, and the overall resource levels needed. • The overall resources used and business benefit delivered tie back to the Business Case developed for the solution. • The overall project plan is a high-level roadmap for the project as a whole. (Chapter 6 – more details) © 2005 Ivar Jacobson International 28

The Current Development Plan • This is the single plan for the current evolution. • The Development Plan describes the lifecycle milestones and goals for each phase. • This plan also identifies the number and purpose of the iterations they contain. (but not too much detail) • The plan may also specify numbers and skills of people needed at different times. – All specialties are not always needed. • As a specific evolution progresses and we see good business value developing, we may start to plan the next evolution. • Producing the Development Plan for an Evolution: (Chap 7) © 2005 Ivar Jacobson International 29

The Current Iteration Plan • There’s a single iteration plan for the current iteration. – Iteration plan is, of course, detailed; describes activities to be done. – Most susceptible to change; this is where the real work occurs. • Note that we do not plan the details of each iteration at start of project. • Thus changes can not domino through an entire set of detailed plans. • As for evolutions, as an iteration progresses and we start to deliver value, the planning of the next iteration starts. (Chapter 8) – In practice, most iterative project managers create a rough draft of the plan for the next iteration alongside the current iteration plan. – As current iteration continues, the draft plan for the next iteration may be modified and slowly evolve into the plan for the next iteration. – Deferred tasks / changes and may fold into the next iteration. • A note of caution: Be careful not to over plan the next iteration before the results of the current iteration are known. © 2005 Ivar Jacobson International 30

Detail Is Pushed Down Into the Iteration Plans As Bittner and Spence suggest, we have ‘Top down’ macro level planning; forward looking, low fidelity, low precision, optimistic. Bottom up: we have micro level planning backward looking, high fidelity, high precision, Evolution 1 pessimistic. Details of plans increase as we go down the layers while the scope of plan narrows. Inception Overall project plan is visible to entire organization, whereas the plan for an iteration is usually only visible to those working on it. The Overall Project Evolution 2 Elaboration Iteration 1 Evolution 3 Construction Iteration 2 Transition Iteration 3 Task 1 Task 2 Task 3 © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 31

Detail Is Pushed Down Into the Iteration Plans Each successive level refines but yet shields us from the details below it. The Overall Project Overall project plan has broadest horizon and focuses on decisions and commitments that affect the project as a whole. Evolution 1 Inception Evolution 2 Elaboration Iteration 1 Details are pushed down through the development plans into the iteration plans. For layering to work, we need to outline the entire project in a robust time neutral manner that accommodates project Over- and under- performance. © 2005 Ivar Jacobson International Evolution 3 Construction Iteration 2 Transition Iteration 3 Task 1 Task 2 Task 3 Iterative Project Management / 03 - Lifecycle Planning 32

Plans Are Achievement Based Overall Project Plan – Business Milestones Coverage - All evolutions Overall Project Plan Focus on achievements, commitments and constraints Development Plan – Technical Milestones Coverage – Development of a Major External Release Development Plan Focus on achievements, commitments, constraints, the current evolution and possibly the next evolution Iteration Plan – Iteration Significant Milestones Coverage – Single Iteration Plan © 2005 Ivar Jacobson International Lower levels must contain detailed info on project activities Iterative Project Management / 03 - Lifecycle Planning 33

The Plans Share Milestones Overall Project Plan – Business Milestones and External Commitments. These are allocated to development projects to be achieved. Provide link between business plans and the development plans. May involve more than just software development. Overall Project Plan Development Plan – Technical Milestones; Single Evolution Developed and Released. Development Plan These are added to provide stepping stones on the way to achieving the business milestones and align the technical development project defined by the UP lifecycle to the overall project plan. Milestones provide structure and focus to reduce risk and encourage progress toward delivery of a major release. Iteration Plan – Iteration focus. Shows how assignment requirements will be developed and how technical risks will be mitigated. Team working plan. Iteration Plan © 2005 Ivar Jacobson International Milestones from the development plan are allocated to iterations. Provides means by which development team coordinates its work within a time box defined by the iteration. Iterative Project Management / 03 - Lifecycle Planning 34

Tolerance – Managing Across the Layers… • A good way is to set and apply tolerances. • Could be related to any of the project drivers; – – scope, cost, time, quality. • Most organizations set tolerances in all of these areas. If the project exceeds, or looks like it is going to exceed its tolerances then the deviations are reported up the levels and new plans need to be made. • Example project tolerances include: • Time tolerance – up to two weeks slippage is allowed • Quality tolerance – no major external release can have any ‘priority one’ defects and no more than three ‘priority twos. ’ • Scope tolerance – All ‘must have’ requirements, at least 70% of ‘should haves’ • Cost – No more than £ 300, 000 © 2005 Ivar Jacobson International 35

• Bittner and Spence elaborate: – The tolerances on the iterations will vary across the iterations and phases. – If we find a priority one defect in the first elaboration iteration this is good, especially if it is in a third party component, as we have plenty of time to get it fixed. – A priority one defect in a late construction iteration, especially if it is in a third party component, is a bit of disaster as there is little time to fix it before the system goes live. © 2005 Ivar Jacobson International 36

Plans Include Tolerances Project Tolerances Overall Project Plan External Release Phase / Tolerances Overall Project Tolerances set by the Business. Development Project Tolerances set by the Overall Project Manager. Development Plan Iteration Tolerances derived from the Development Plan. Iteration Plan Note that the tollerances are established by the next ‘higher up’ Concern…. © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 37

Deviations Cause Replanning Project Tolerances Overall Project Plan External Release / Phase Tolerances If the project exceed or looks like it will exceed its tolerances, then the deviations are reported up the levels and new plans need to be made. Re-plan Development Plan Iteration Tolerances Poor Iteration Performance Project Plan Deviations External Release / Phase Deviations Iteration Plan © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 38

Key Management Roles Overall Project Manager Development Project Manager Iteration Lead Note: These are roles that need to be filled on the project. This does not mean that every project needs three managers. In many cases all three roles will be fulfilled by one person: the project mgr. For larger, or more formal projects, it is not unusual for the roles to be shared among a number of people often with a more senior project manager in the Overall Project Manager, a specialist development manager in the Development Project Manager Role and team leaders taking on the role of Iteration Lead. © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 39

Management Responsibilities and Reviews The three management roles share the responsibilities of the traditional UP Project Manager role. Role Responsibilities Gateway Review Overall Project Manager Overall Project Planning Set the management strategy Stage Reviews Overall Project Close-down Development Project Evolution Planning Manager Iteration Lead Iteration Planning Team leading Phase Reviews and Software Project Close-down Iteration Assessment For the project to be ‘joined up’ the management must work as a team to plan and assess the project. © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 40

Discussion: What Are Your Projects Like? • • How many external releases do you have? Who commissions / supervises your projects? How many levels does your project have? How far ahead do you plan? What kind of projects do you manage? What is the structure of your management team? What constraints do you operate under? What problems do you have? What Does Iterative Planning Change? © 2005 Ivar Jacobson International Iterative Project Management / 03 - Lifecycle Planning 41