Iterative Project

Management
Lifecycle Planning
Chapter 6.1 Overall Project Planning
Modified Considerably by your Instructor

Preface to Overall Project Planning

Well into this chapter, the authors state that they
had a number of reservations about including this
chapter.
They particularly did NOT want to give the
impression that an entire project can be planned up
front before any iterations take place.
They assert that one must balance
high-level life-cycle planning with
low-level execution of the iterations.

2005 Ivar Jacobson International

Preface to Overall Project Planning

Planning is essential at various levels, but one must
not obsess too much about where you are going to
end up you are unlikely to go anywhere.
Unfortunately, while much of the material might
appear to be common sense, people under
pressure to deliver frequently
lose common sense in planning and
ignore several of the sacred principles.

Plan well,
Plan carefully, and
Trust your plans
2005 Ivar Jacobson International

Introductory Remarks Overall Project Plan

Overall project plan
Should be lightweight plan
Should summarize long-term direction for the
project
Should identify major releases to be produced
Should identify business benefits to be realized.
Should be simple,
Should ensure project is in synch with the
organization,
Should enable project integration with any
strategic or higher-level program management
plans, and
Should provide the context for successful
iterative development of the software products.
2005 Ivar Jacobson International

Initial Questions
Important initial questions re: Overall Project Plan:
Single or multiple releases?
When are specific business capabilities needed?
Can some requirements be delayed to deliver others early?
What are the latest date decisions can be made without
impeding the business?
How can work be organized to accomplished all this with
time and resources provided?

2005 Ivar Jacobson International

Initial Questions

So we develop a project roadmap.

An overview of all major releases, goals, major
requirements and risks and strategy for how and when
you will make critical decisions.
If several major releases, then development projects
will drive all this in the form of evolutions.
Major releases will evolve into the overall software
solution.

2005 Ivar Jacobson International

Evolution and Release Planning

Most significant question is, What is the release strategy?
How often? How significant of a release?
Most projects plan major releases along with provisions
for additional point releases that address smaller issues
(quality, smaller / minor enhancements).
Large number of deliveries? Likely not tolerable by the
business.
Single UP evolution? (major release at the end of a long
period) may also be equally undesirable as business value
is not delivered frequently enough.
Alternatives include shortening Elaboration and
Construction, send out a release, and then use Transition
to clean things up. In here, have a number of short-term
releases
2005 Ivar Jacobson International

Evolution and Release Planning - more

Probably best approach is to stage major releases
with contents dictated by business concerns, such that
each evolution is a planned delivery. (four slides up)
There is a balancing act here: balance number of major
releases with rate the business can absorb them. (Not
always easy)
To do this, need to layer plans to support such a strategy
Simple Overall Project Plan for the project: focuses only on
the major releases (in terms of evolutions) and the associated
commitments made to the business, and
Low level development plan: describes how evolution will be
realized.

How about addressing risks in three major releases?

2005 Ivar Jacobson International

Moving Risks Around in Multiple Evolutions

Can spread risk around in some cases?

May allow project to adapt to time, scope, cost, and resource constraints
It may be that the success criterion is first to market.
So it might be better to defer architectural risk mitigation until after initial
delivery.
Might be the way to go, but
Might need to rewrite a lot if the architecture changes substantially.

Evolution planning, as part of the overall project planning, must

explicitly describe the release strategy and allow for some
conscious trade-offs of business and technical risks.
Strategies for balancing risks across evolutions include:
pulling some risks forward or
pushing some risks backwards.

Advantages and disadvantages to each approach. What are they?

2005 Ivar Jacobson International

Handling Sequential Evolutions

Most evolutions are sequential with some small overlap.
Overlap is VERY important. It can provide for
more efficient use of some resources (people with special skills, )and
reduce total elapsed project time (some parallel activities).

Rules that apply when planning evolutions:

1. An evolution cannot complete a phase before the previous
evolution has completed the same phase.
2. An evolution should not enter the Elaboration Phase before
the previous evolution has exited its Elaboration Phase.
3. The more overlap, the more work that occurs in parallel the
more potential for conflicting changes.
2005 Ivar Jacobson International

Overlap Patterns:
Most typical overlap patterns are: (next slide for visual)
overlap of Inception phase of next evolution with
Transition phase of current evolution, or
Overlap of Inception phase with latter iterations of the
Construction Phase of the current evolution.
This is because the inception, construction, and transition
phases do not affect the architecture of the overall
solution, so dependencies are greatly reduced enabling
work to proceed in parallel.

2005 Ivar Jacobson International

Benefits Realization and External Release Planning

Initiation

Stage 1

Stage 2

Stage 3

Stage 4

Release 1
Inception

Elaboration

Con

Trans

Release 2
Inc

Elab

Con

Trans

Release 3
Inc

Elab

Con

Trans

Marketing and Communications

Training
Hardware Roll-out

Adapted from the PRINCE2 manual: Figure 16.6 page 237

2005 Ivar Jacobson International

Benefit Delivery

Iterative Project Management / 03 - Lifecycle Planning

12

Multiple Evolutions
Are many incentives for early and frequent product
deliveries.
Particularly true when key functionality may be
deliverable early prior to the rest of the system being
needed.

This may be good for morale and team visibility.

Converse is also possible and highly undesirable!
Remember: planning a solution across evolutions is a
roadmap not a detailed plan.
2005 Ivar Jacobson International

Deployment of Multiple Evolutions

Multiple Evolutions may
Provide earlier solution delivery / deployment
Provide a focus for architectural work in each evolution
Avoid the big bang business change and migration
Enable project to be split up into smaller, sequential projects
Enable maintenance and support to be factored into plans
Enable alignment to the organizations budget cycles, and
more.

2005 Ivar Jacobson International

Number of Evolutions? What are the Factors to Determine?

Many: (Book)

Length of time business can wait for a solution

Sponsoring organizations sense of urgency
Budget cycle and funds available
Size and complexity of the deployment
Window of opportunity for deployment
Infrastructure and technology cycles
Degree to which requirements can be deployed separately
Degree to which different stakeholder communities require
different capabilities and services.

Deliver solution in a series of progressively more functional

releases.
Be careful to have a stable architecture for consistency across a
series of releases.
Architecture must be stabilized for the functionality of the solution
to be partitioned.
2005 Ivar Jacobson International

Style of the Overall Project Plan

Only difference between planning for conventional vs iterative
approach is that layering removes unnecessary detail from the highlevel plans enabling the overall plan to focus on business
commitments, notable achievements, management decision points.
Senior managers often feel iterative project is:

uncontrolled technical development with

no proper (in their perspective) long-term plans,
little visibility of whats taking place, and
ineffective management controls.

But overall project plan can provide appropriate visibility

Note: senior management doesnt care about development techniques
They
Do care if the project is out of control and
Do care if there are no long-term plans to illustrate where project is
heading.
Do care if only have a plan for the next iteration and nothing beyond.
2005 Ivar Jacobson International

So we have: Lifecycle Planning

Stage Planning
Identifying the major evolutions / external releases and business
decision points

Evolution / External Release Planning

Defining the number of evolution cycles required

Phase and Iteration Planning

Relating the business and technical milestones
Planning the phases and iterations

Lifecycle planning is required at all levels of the project.

2005 Ivar Jacobson International

Iterative Project Management / 03 - Lifecycle Planning

17

Principles of Lifecycle Planning

(bold type is mine)

Understand the desired outcomes
Identify and assess overall risk
Set the management strategy
Create an achievement-based roadmap
Understand the solution and its scope
Assess and estimate the work to be done
Define the project plans
Delegate the execution of the plans
Iteratively evolve and challenge the plans

2005 Ivar Jacobson International

Iterative Project Management / 03 - Lifecycle Planning

18

Principles of Lifecycle Planning first three

First three principles define risks, objectives, and constraints
(Arrows are mine)
Understand Desired Outcomes
Make sure you understand what you want to achieve.
Focus on value delivered to whom not the activities undertaken
or artifacts addressed
Identify and assess risks
Anticipate obstacles to achieving the desired outcomes.
Set the management strategy
What is the approach to manage and control the project?
What are the processes to follow, how results will be
measured, how progress will be reviewed, events reported,
decisions made..
2005 Ivar Jacobson International

Next Three: - from book:

Next three principles establish project roadmap.
Low precision but high fidelity provides big picture view.
Create an Achievement-based Roadmap
Shows fundamental things to be achieved, their order,
dependencies, and maybe which ones can be deployed
together.
Products produced, dates needed,
Does NOT show who will do the work or how long the work
will take! It is a roadmap not a plan.
Understand the Solution and its Scope
Determine project scope; boundary of the solution and
quality and other ility requirements.
Heres where use cases and other requirements artifacts are
important.
Assess and Estimate the work to be done
Assess current state of project; how much effort the project
will take to complete, determine resources needed, etc.
2005 Ivar Jacobson International

Last Three directly from Book (arrows are mine):

Enable more detailed project plans to be agreed

upon, executed, tested, challenged, and improved.
Secure agreement on the Project Plan(s)
Identify dates for milestones lying within the current event horizon
and define tolerances related to each milestone.
For each subproject identified, apply appropriate life cycle to ratify
plans and introduce additional milestones,
Add management review points required to control project risk.
Facilitate the Execution of the Plan(s)
Executing plan asap. Planning without execution produces nothing.
Iteratively Evolve and Challenge the Plan(s)
Overall project plan is only a sketch to be elaborated, expanded, and
adapted as the project progresses.
Its main purpose is to provide the vision and roadmap of where the
project is going and what it is trying to achieve. This will enable the
business context and understand whether they are headed for success
or failure.
2005 Ivar Jacobson International