iterative project management lifecycle planning chapter 5 – a layered approach to planning and...

Iterative Project Management

Lifecycle Planning

Chapter 5 – 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

• Two prongs here:– Management and then– Planning.


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.

4Iterative Project Management / 03 - Lifecycle Planning


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


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,



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.



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.


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

Planning at Multiple Levels

Program Management (Benefits Realization)

Overall Project Management (Benefits)

Adapted from Implementing RUP Within a PRINCE2 Environment: Laurence Archer, Oak IT, 2001

Software Development (External Releases)

It 1 It 2 It 3 It 4 It N-1 It N……

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)

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.

10

© 2005 Ivar Jacobson International

Let’s look at these layers of management:Let’s look at these Management layers


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.


12


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.

13


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.

14


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.

15


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.

16


• We’ve talked about the layers.• Now let’s talk about the plans….

17


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.

18


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.

19


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.

20


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.

21


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.

22


23


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!

24


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.

25

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

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

26


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.

27


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.

28


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)

29


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)

30


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.

31


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.

32


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.

33


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 possibly the next evolution

Iteration Plan – Iteration Significant Milestones

Coverage – Single Iteration

Lower levels must contain detailed info on project activities

34


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 are allocated to iterations. Provides means by which development team coordinates its work within a time box defined by the iteration.

35


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

36


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

37


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 tollerances are established by the next ‘higher up’ Concern….

38


Deviations Cause Replanning


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.

39


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.

40


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.

41


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?

iterative project management lifecycle planning chapter 5 – a layered approach to planning and...

Documents

iterative planning

detailed planning

lifecycle planning slide

undertaken planning

lifecycle planning objectives

ivar jacobson international

external release planning

successful iterative