Transcript Project Planning

Software Project Planning
“Weeks of programming can save
you hours of planning.”
Introduction
• Planning is critical to project success.
• In one study of over 250 large projects,
Capers Jones found a strong correlation
between planning and project outcomes.
Successful projects were always wellplanned and failing projects nearly always
had inadequate plans [Jones Crosstalk Oct
2004].
The reasons for planning a project are a lot
like the reasons for planning a vacation.
• In both cases there is a limited amount of time and
money. You can make the most of limited
resources by planning ahead.
• You are likely to avoid many problems by
thinking through them in advance of starting on
your journey.
• There is no confusion about what to do each
day—the plan provides optimal direction.
Vacation Analogy [cont]
• The plan serves as a baseline for tracking progress and
controlling performance.
– Tracking Progress: “Are we there yet?” “I don’t know, let me look
at the plan. No, we aren’t there yet, but according to the plan we
will be there in 3 hours.”
– Controlling performance: On the third day you notice that you are
consistently underachieving. Each day you are seeing on average
half of what you planned to see. Some analysis of the problem
reveals you are spending much more time than anticipated on
meeting and coordinating individual activities. You decide to
purchase walky-talkies so you can better coordinate activities.
• Detailed planning results in better estimates. The guide
said “Europe on $100 a day,” but after detailed planning
you conclude that for the kind of trip you have in mind it’s
more like $300 a day.
Reasons for Planning a Project
• You can avoid problems and rework by thinking through your
actions before performing them.
• Plans serve as a baseline for tracking progress and controlling
performance. A project can’t be “on track” unless there is a plan
with which to compare actual progress against.
• Detailed planning provides for more accurate bottom-up
estimates.
• Planning and the schedules that come from planning establish
commitments that others outside the project can use to make
their own plans and commitments.
• A plan serves as roadmaps for completing the work of a project.
• A plan is a tool for gaining visibility into a project.
• Planning provides for more efficient and effective use of
resources.
Project Lifecycle
• The software development
process is iterative and
incremental
• Artifacts are progressively
refined over a series of
iterations
• Planning is divided between
initial planning (step 4),
release planning (step 5) and
iteration planning (step 6).
• Product architecture shapes
project planning.
Inputs and Outputs of Project Planning
Four main components of a
project plan
• Not surprisingly, the four main components of the
project plan are closely aligned with the four main
variables of a project. A full project plan will have:
– A budget for managing the cost component
– A schedule for managing the time component
(most notably, delivery date).
– A release plan for managing the scope of the
project.
– A quality plan for managing product quality.
Release Plans and Iteration Plans
• On an iterative project, two kinds of plans
are useful [Kruchten 2002]:
– A release plan, one per project, which specifies
the timing of iterations and a rough allocation
of product features to iterations.
– Iteration plans, one per iteration, which specify
the detailed tasks for an iteration, and in some
cases an assignment of tasks to individuals.
Release Plan compared to
Iteration Plans
Internal and External Releases
• There are three important opportunities for
feedback and control: during frequent integration,
at the end of an iteration with an internal release
and at the end of an iteration with an external
release.
Predictive and Adaptive Planning
• There is a range of planning options
available to the project manager from
adaptive to predictive:
Adaptive Planning
• With adaptive planning, near-term work is
planned in detail and work further out in the
schedule is planned at a higher level of
abstraction.
• Adaptive planning is the idea of progressive
elaboration applied to project planning.
• Note that adaptive planning is not the same as
doing little or no planning. With adaptive planning
there are detailed plans; they just aren’t longrange. There are long-range plans; they just aren’t
detailed.
Predictive Planning
• Predictive planning starts with a major upfront
effort to understand product requirements.
This knowledge is used to construct a detailed
plan for implementing the product definition.
• Predictive planning is most effective when
requirements are well-understood and stable.
• Changes are permissible and are handled
according to formal change control procedures.
How much planning is enough?
Home ground for adaptive and
predictive planning
Planning Horizon
• A project’s planning horizon is the distant
into the future in which work items are well
understood.
Finding the Right Balance
Some projects need
more planning
Some are better off with less
Planning
Process
Work Breakdown Structure
(WBS)
• Creating a WBS is a systematic way of identifying
the tasks needed to complete a project.
• It provides a hierarchical decomposition of the
work.
• A WBS can be presented in graphical or outline
form.
Widget Project
1.0 Initiate
2.0 Define Requirements
2.1 Gather Requirements
2.2 Analyze Requirements
2.3 Document Requirements
3.0 Plan
...
WBS Structure
• There are two types of tasks:
– Summary, and
– Detailed elemental tasks (aka work packages)
• Summary tasks may be activities or deliverables.
Summary tasks always have detailed subtasks.
• Detailed tasks are always the actual schedulable
tasks. They are leaf nodes in the WBS hierarchy.
Widget Project
1.0 Define Requirements
1.1 Gather Requirements
1.2 Analyze Requirements
1.3 Document Requirements
2.0 Plan Project
...
Widget Project
1.0 Requirements Document
1.1 Gather Requirements
1.2 Analyze Requirements
1.3 Document Requirements
2.0 Software Project Management Plan
...
Work Packages
• Information needed for each schedulable task or
work package:
–
–
–
–
–
Tasks description
Owner
Schedule start and stop date
Effort estimate
Expected output or deliverable (optionally with
completion/acceptance criteria)
– Staff and material resources needed to complete the
task.
Task Dependencies
• Before you can schedule tasks you have to know
the predecessor and successor relationships
between tasks.
Network Diagram
• The standard dependency between nodes in a
network diagram is finish-to-start. That is, if there
is a finish-to-start dependency from A to B, A must
finish before B starts.
Types of Dependencies
• Finish-to-Start - Task A must finish before task B
can start. This is the most common type of
dependency.
• Finish-to-Finish - Task A must finish before task
B finishes. This is common with work that is
largely sequential but can also benefit from
feedback from downstream activities
• Start-to-Start - Task A can not start until task B
starts.
• Start-to-Finish - Task A must start before task B
finishes. This dependency is rarely used.
Estimation
• Effort and duration estimates are made for
each task.
• After scheduling, these estimates are rolled
up (bottom-up estimation) into overall
estimates for project cost and duration.
• There are several estimation techniques that
may be used (analogy, algorithm models,
expert opinion, etc.)
Effort vs. Duration
• Effort is the amount of labor required to
complete a task, typically measured in terms
of person months or person hours.
• Duration is the amount of calendar time or
clock time needed to complete a project or
task.
• Effort is used to measure resource usage
and duration is used in scheduling.
Effort vs. Duration—Example
Ironing a shirt
Effort = 10 minutes
Duration = 10 minutes
Cooking a turkey
Effort = 1 hour
Duration = 3 hours
Cutting a tree with a two-person saw
Effort = 30 minutes
Duration = 15 minutes
Scheduling
• The Gantt chart is probably the most common tool
for presenting schedule information. It shows start
and and stop types for tasks in a visually
recognizable calendar form. It also shows timing
of milestones.
Critical Path Analysis and Float Time
• The critical path is the longest sequence of activities in the
network diagram. A delay for any activity on the critical
path will delay the project completion date.
• Free slack - the amount of time a task can slip without
delaying another task.
• Total slack -the amount of time a task can slip without
delaying the project completion date
Order of Events
•
Is it better to
Assign resources  Estimate effort  Schedule
OR
Estimate effort  Schedule  Assign resources
Resource Leveling
Documenting the Plan
• There is significant value in just planning
• Most projects will also need a written plan
which documents the planning work done
• Software Project Management Plan (SPMP)
A comprehensive SPMP will address the following items:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Project goals and objectives
Major milestones and deliverables
Priorities and constraints
Work breakdown structure (WBS). The WBS fleshes out the detailed tasks that must be
completed in order to accomplish the goals of the project.
Schedule which shows the timing of major milestones and deliverables. As much as
possible, work should be planned in units of customer-visible functionality [Beck 2005].
The schedule should show timing of iterations and features planned for each iteration.
Estimates for cost, effort and duration.
Project budget. The budget shows expenditures over time.
Organizational structure including project roles, lines of authority and reporting
relationships. The organizational structure may also include an initial assignment of
people to roles.
Configuration Management Plan.
Risk Management Plan. The risk management plan identifies threats to project success
and documents the planned actions for mitigating these threats.
Communication Plan - A project's communication plan states: (1) what information is
collected and by whom, (2) to whom the information should flow and by what method,
(3) a schedule for producing and disseminating the needed information.
Metrics collection plan
Status and progress reporting
Communications Planning
• During the course of a project people need
information in order to do their job
• Communication planning is the process
of…
– Determining the information needs of each
stakeholder, and
– Making sure the needed information is created
and delivered to the right people at the right
time in the right format
Creating a Communication Plan
1. Determine the information and
communication needs of each stakeholder
2. Determine the source of the needed
information
3. Decide on the format and frequency of
distribution
4. Create a plan for the free flow of
information during the project
Determining the Information
Needs of Stakeholders
• Standard stakeholder roles include: customer,
users, project sponsor, project manager,
developers, senior management, etc.
• Stakeholder information needs include: Summary
project status, detailed project status, task
assignments, solutions to technical problems,
product quality, changes and updates to
requirements/scope/plan, major risks and risk
mitigation strategies, issues and problems,
forecasts, lessons learned.
Example: Stakeholders and Their
Information needs
Sources of Information
• Most information passes directly from one
individual to another, but may also be
stored for later use.
• Example information stores:
– Issues database
– Configuration management system
– Process assets database
Format and Timing
• Format dimensions: formal / informal;
written / verbal; push / pull.
• Example formats: email, memo, written
report, casual conversation, meeting,
telephone/conference call, white paper,
presentation, web site, Wiki
• Example timings: weekly, monthly, on
demand, project closeout.
Documenting the Communication Plan
• The communication plan states:
– What information is collected and by whom
– To whom the information should flow and by what
method
– A schedule for producing and disseminating the needed
information
• The communication plan may also include
guidelines and procedures for communications
(e.g. guidelines for conducting an effective team
meeting)
• Change control and issue tracking are typically
described outside of the communication plan
Sample Communications Plan
Informal Spontaneous
Communication
• Informal spontaneous communication is an
important form of information exchange.
• Although, planned spontaneous communication
might seem like a contradiction in terms, it is
reasonable to make plans to foster (or at least not
hamper) the opportunity for spontaneous
communication [example from psychology of
computer programming].
• Part of communications planning is taking steps to
nurture the opportunity for informal spontaneous
communication
Team Meetings
• Holding a regularly scheduled team meeting (weekly for
most projects) is one of the best ways to keep everyone
informed, identify problems, make decisions, build
relationships and establish commitments.
• The basic agenda for a team meeting is to have each
individual or group representative briefly present:
– What was accomplished since the last meeting?
– What work is planned between now and the next meeting?
– What issues or problems are blocking progress?
• The team meeting isn’t the forum for solving problems.
Problems are better handled in smaller groups outside of
the team meeting
Configuration Management
• The freedom to
change a
document is
more restricted
after the
document is
baselined.
Change
Control
Procedure
Timing
• The planning phase of the project life cycle comes after
some portion of the product requirements are known
• The output of planning is a project plan which provides
direction for the remainder of the technical development
activities.
• The project plan sets a course of action for accomplishing
the goals and objectives outlined in the project charter
Communication Planning
• During a project people need information in
order to do their job
• Communication planning is about…
– Determining the information needs of each
stakeholder, and
– Creating a plan that ensures needed information
is delivered to the right people at the right time
in the right format
Selecting a Methodology
• Just as the plans used to built most homes
are adaptations from generic plans that fit
within certain architecture styles, most
software development plans are adaptations
of generic plans that fit within a certain
software development methodology.
• For example, a group might select to use
Extreme Programming (XP) with formal
inspections in place of pair programming.
New Slides
Progressive Elaboration
• The major artifacts and deliverables associated
with a software project are rarely created and
finalized in one step.
• More often they are conjured up in a primitive
form and evolved over time to become more
explicit and detailed.
• It’s generally easier to grow a complicated and
complex artifact than it is to engineer one in a
single step.
• created in a primitive ini
• tend to evolve over time becoming more explicit
and detailed over time as more information
becomes available. through a process of