Iterative Project Management
Lifecycle PlanningChapter 5 – A Layered Approach to Planning and
Managing Iterative ProjectsModified 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.
4© 2005 Ivar Jacobson International
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
5© 2005 Ivar Jacobson International
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!”
6© 2005 Ivar Jacobson International
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,
6Iterative Project Management / 03 - Lifecycle Planning
7© 2005 Ivar Jacobson International
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.
7Iterative Project Management / 03 - Lifecycle Planning
8© 2005 Ivar Jacobson International
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.
8Iterative Project Management / 03 - Lifecycle Planning
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
11© 2005 Ivar Jacobson International
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.
11Iterative Project Management / 03 - Lifecycle Planning
12
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
• We’ve talked about the layers.• Now let’s talk about the plans….
17
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
23
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International 26Iterative Project Management / 03 - Lifecycle Planning
How Many Plans Do You Need? This says it all.
Overall Project Plan
Iteration Plan
Iteration 1 Iteration 2 Iteration 3
Inception
Evolution 1 Evolution 2 Evolution 3
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
© 2005 Ivar Jacobson International 27Iterative Project Management / 03 - Lifecycle Planning
High Level Plans Focus On Achievements
Iteration 1 Iteration 2 Iteration 3
Inception
Evolution 1 Evolution 2 Evolution 3
The Overall Project
Task 1
Task 2
Task 3
Elaboration 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!
These release numbers would be the resultof undertaking Transition iterations as part of first evolution.
28
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International 31Iterative Project Management / 03 - Lifecycle Planning
Detail Is Pushed Down Into the Iteration Plans
Iteration 1 Iteration 2 Iteration 3
Inception
Evolution 1 Evolution 2 Evolution 3
The Overall Project
Task 1
Task 2
Task 3
Elaboration Construction Transition
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
© 2005 Ivar Jacobson International 32Iterative Project Management / 03 - Lifecycle Planning
Detail Is Pushed Down Into the Iteration Plans
Iteration 1 Iteration 2 Iteration 3
Inception
Evolution 1 Evolution 2 Evolution 3
The Overall Project
Task 1
Task 2
Task 3
Elaboration Construction Transition
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
© 2005 Ivar Jacobson International 33Iterative Project Management / 03 - Lifecycle Planning
Plans Are Achievement Based
Overall Project Plan
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 IterationLower levels must contain detailed info on project activities
34
© 2005 Ivar Jacobson International 34Iterative Project Management / 03 - Lifecycle Planning
The Plans Share Milestones
Overall Project Plan
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
© 2005 Ivar Jacobson International
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
© 2005 Ivar Jacobson International
• 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
© 2005 Ivar Jacobson International 37Iterative Project Management / 03 - Lifecycle Planning
Plans Include Tolerances
Overall Project Plan
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
© 2005 Ivar Jacobson International 38Iterative Project Management / 03 - Lifecycle Planning
Deviations Cause Replanning
Overall Project Plan
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
© 2005 Ivar Jacobson International 39Iterative Project Management / 03 - Lifecycle Planning
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
© 2005 Ivar Jacobson International 40Iterative Project Management / 03 - Lifecycle Planning
Management Responsibilities and Reviews
Role Responsibilities Gateway Review
Overall Project Manager
Overall Project PlanningSet the management strategy
Stage ReviewsOverall Project Close-down
Development Project Manager Evolution Planning Phase Reviews and Software
Project Close-down
Iteration LeadIteration PlanningTeam leading
Iteration 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
© 2005 Ivar Jacobson International 41Iterative Project Management / 03 - Lifecycle Planning
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?
Top Related