Iterative Project Management Lifecycle Planning Chapter 5.2 – Second Part: A Layered Approach to Planning and Managing Iterative Projects Modified considerably

Iterative Project Management

Lifecycle Planning

Chapter 5.2 – Second Part: A Layered Approach to Planning and Managing Iterative Projects

Modified considerably by your Instructor

2© 2005 Ivar Jacobson International 2Iterative Project Management / 03 - Lifecycle Planning

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

3© 2005 Ivar Jacobson International

Positioning the Unified Process Lifecycle• Will use the UP as our framework for controlling iterative

development. 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.– Personally, I’ve never been on one – that sat alone…

– Have a series of major, sequential releases; build on previous releases; ‘mod1,’ ‘phase II,’ or whathaveyou.

– Each evolution delivers major benefit to clients.


Layering the Plans and Milestones

• Planning effects a separation of concerns, as mentioned.• 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.

• 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.

– High-level plans are necessarily abstract…

• Need low level plans to get the work done – particularly in an iterative, agile fashion.– Detailed, specific plans; remember: work gets done here!


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 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!


Overview of all three Plans: Very Important Slide:

Overall project describes the development projects. Development projects are each an evolution of a product Each evolution is managed iteratively using 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 in the evolution.• As this iteration progresses and its results start to become

apparent the planning of the next iteration starts.


How Many Evolutions / External Releases?

The reality is that very few projects deliver a single external release– One pass through the Unified Process lifecycle

Most projects deliver the system in series of major external releases– Multiple passes through the lifecycle

Inception Elaboration Construction Transition

One evolution, deploying one major external release

Evolution 1 Evolution 2 Evolution 3

Multiple evolutions, each deploying a major external release


How Many Plans Do You Need? This says it all.

Overall Project Plan

Iteration Plan

Iteration 1 Iteration 2 Iteration 3

Inception


The Overall Project

Task 1

Task 2

Task 3

Elaboration Construction Transition

Development Plan

One for the current iteration plus, possibly, the outline of the next.

While there may be some variation, in general each plan can be (and probably should be) no longer than a few pages.


High Level Plans Focus On Achievements


Inception


The Overall Project

Task 1

Task 2

Task 3


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!

These release numbers would be the resultof undertaking Transition iterations as part of first evolution, hence Release 1.x numbers.

10

© 2005 Ivar Jacobson International

The Overall Project Plan

• Each major project has a single, brief, overall project plan.• Will contain a number of evolutions and anticipated major

releases needed to provide the overall solution.– These can come from the major planning, vision, overall functionality

needed, etc.

• This plan should include – Overall milestone dates, – functionality delivered, (prioritized and when needed) – 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)


The Current Development Plan (Evolution; Life Cycle)

• This is the single plan for the current evolution.• The Development Plan describes the lifecycle milestones

(e.g. LCA, IOC, etc.) and goals for each phase.• This plan also identifies the number and purpose of the

iterations they contain. (but not much detail for the iterations.) Iteration goals are identified.

• 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 and ‘firm up’ the next evolution.

• Producing the Development Plan for an Evolution: (Chap 7)

12


The Current Iteration Plan

• There’s a single iteration plan for the current iteration.– Iteration plan is detailed; describes activities to be done.– Most susceptible to change; real work occurs.

• Note we do not plan details of each iteration at start of project.• Precludes changes propagating through entire set of detailed

plans.• As done for evolutions, as an iteration progresses and starts 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 next iteration.

– Deferred tasks / changes and may fold into the next iteration.

• Book note of caution: Be careful not to “over plan” the next iteration before the results of the current iteration are known.

13

© 2005 Ivar Jacobson International 13Iterative Project Management / 03 - Lifecycle Planning

Detail Is Pushed Down Into the Iteration Plans


Inception


The Overall Project

Task 1

Task 2

Task 3


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, pessimistic.

Details of plans increase as we go down the layers while the scope of plan narrows.

Overall project plan is visible to entire organization, whereas the plan for an iteration is usually only visible to those working on it.

14


Detail Is Pushed Down Into the Iteration Plans


Inception


The Overall Project

Task 1

Task 2

Task 3


Each successive level refines but yet shields us from the details below it. Overall project plan has broadest horizon and focuses on decisions and commitments that affect the project as a whole.

Details are pushed down throughthe development plans into the iteration plans.

For layering to work, we need to outline the entire project in a robust time neutralmanner that accommodates project Over- and under- performance.

15


Plans Are Achievement Based


Iteration Plan

Development Plan

Overall Project Plan – Business Milestones

Coverage - All Evolutions

Focus on achievements, commitments and constraints

Development Plan – Technical Milestones

Coverage – Development of a Major External Release

Focus on achievements, commitments, constraints, the current evolution and some of the next evolution

Iteration Plan – Iteration Significant Milestones

Coverage – Single Iteration

Lower levels must contain detailed plan on project activities

16


The Plans Share Milestones


Iteration Plan

Development Plan

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.

Development Plan – Technical Milestones; Single Evolution Developed and Released.

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.

Milestones from the development plan - allocated to iterations. Provides means by which development team coordinates its work within a time box defined by the iteration.

17


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

18


• Bittner and Spence elaborate:

– The tolerances on the iterations will vary across 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.

19


Plans Include Tolerances


Iteration Plan

Development Plan

Overall Project

Tolerances set by the Business.

Development Project

Tolerances set by the Overall Project Manager.

Iteration

Tolerances derived from the Development Plan.

Project Tolerances

External Release Phase /

Tolerances

IterationTolerances

Note that the tolerances are established by the next ‘higher up’ Concern….

20


Deviations Cause Re-planning


Iteration Plan

Development Plan

Project Tolerances

External Release /

Phase

Tolerances

Poor Iteration Performance

IterationTolerances

Project Plan DeviationsRe-plan

External Release /

PhaseDeviations

Iteration Deviations

Re-plan

If the project exceed or looks like it will exceed itstolerances, then the deviations are reported up the levels and new plans need to be made.

21


Key Management Roles

Overall Project Manager

Development Project Manager

Iteration Lead

Note: These roles need to be filled. Does not mean 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 Development Project Manager Role

• and team leaders taking on the role of Iteration Lead.

22


Management Responsibilities and Reviews

Role Responsibilities Gateway Review

Overall Project Manager

Overall Project Planning

Set the management strategy

Stage Reviews

Overall Project Close-down

Development Project Manager

Evolution PlanningPhase Reviews and Software Project Close-down

Iteration LeadIteration Planning

Team leadingIteration Assessment

For the project to be ‘joined up,’ the managementmust work as a team to plan and assess the project.

The three management roles share the responsibilities of the traditional UP Project Manager role.

23


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?

Documents

Iterative Project Management Lifecycle Planning Chapter 5.2 – Second Part: A Layered Approach to Planning and Managing Iterative Projects Modified considerably