Project planning (Lecture 2)

Software Project Planning

• Goal is to establish a practical strategy for controlling,
tracking, and monitoring a complex technical project
• Must deal with:
– Project complexity: has a strong effect but is heavily
influenced by past practitioner experience
– Project size: as size increases the interdependency of
elements also grows. Watch out for scope creep (when
customers change requirements mid-cycle)
– The degree of structural uncertainty: the degree to which
requirements are solidified and the ease of functional
decomposition
• The purpose of project planning is to ensure that the
end result is completed on time, within budget, and
exhibits quality!
Cont.
• Project planning takes place at three stages in a
project life cycle:
— A t t he pro po sal st age : d e c i d e i f we hav e t he
resources to complete the work and to work out the
price that we should estimate to a customer.
— During the project startup phase: when we have to
plan who will work on the project, how the project will
be broken down into increments, how resources will
be allocated across our company, etc.
— Periodically throughout the project: when we modify
our plan in light of experience gained and information
from monitoring the progress of the work.
Steps in Project Planning

— Scope — understand the problem and the work that

must be done.
— Estimation — how much effort? how much time?
— Risk — what can go wrong? how can we avoid it?
what can we do about it?
— Schedule — how do we allocate resources along the
timeline? what are the milestones?
— Control strategy — how do we control quality? how
do we control change?
Scope
• A bounded description of the data and control,
function, performance, constraints, interfaces
and reliability
• Sufficient to determine project feasibility and
create an initial plan
• Scoping Techniques:
– FAST (Facilitated Application Specification Technique), QFD
(Quality Function Deployment), Use-Cases
o Scope is affected by:
o Customers’ needs
o Business context
o Project boundaries
o Customers’ motivation
o Likely paths for change
Estimating Resources
• Human Resources:
— Select skills required (both position and specialty, e.g.
database software engineer). Requires an effort
estimate
• Reusable Software Resources:
– Off-the-shelf components (existing software acquired from
3rd party with no modification required)
– Full-experience components (previous project code is
similar and team members have full experience in this
application area)
– Partial-experience components (existing project code is
related but requires substantial modification and team has
limited experience in the application area)
– New components (must be built from scratch for this
project)
Cont.
• Environmental Resources:
— The hardware and software tools required to
develop the project. Planner needs to provide a time
window for booking them
Estimating Cost and Effort
• Project scope must be explicitly defined. If not,
the project may be infeasible
• Task and/or functional decomposition is
necessary
• Historical measures (metrics) are very helpful
• Triangulation: At least two different techniques
should be used. Can be reconciled if they are
within 20%
• Remember that uncertainty is inherent in early
estimates
Cont.
• Viable Techniques:
— Delay estimation until later in the project
— Base estimates on similar projects that have already been
completed
Cont.
• Use relatively simple decomposition techniques (LOC or FP)
Risk Management
What is Risk
• The possibility of suffering loss
— Webster's dictionary, 1981
• The measure of the probability and severity of adverse
effects
William W. Lawrence, “Of Acceptable Risk”, 1976
• Uncertainty - an event may or may not happen
Loss - an event has unwanted consequences or losses
Risk Analysis and Management
Definition of risk
— Concerns future happenings. What risks might cause
the project to go wrong?
— Involves change. How will changes in customer
requirements, development technologies, target
computers, and other entities affect timeliness and
success?
— Requires choice. What methods and tools should be
used, how many people should be involved to reduce
risk?
o What can go wrong?
o What is the likelihood?
o What will the damage be?
o What can we do about it?
Reactive Versus Proactive
• Reactive
— monitors the project for likely risks.
• Proactive
— begins long before technical work is initiated.
Potential risks are identified,
— their probability and impact are assessed,
— they are ranked by importance
— the software team establishes a plan for managing
risk.
Categories of risks
• Project risks: threaten the project plan. That is, if
project risks become real, it is likely that the
project schedule will slip and that costs will
increase.
• Project risks identify
– potential budgetary
– Schedule
– personnel (staffing and organization),
– Resource
– stakeholder,
– requirements problems and their impact on a software
project.
Cont.
• Tec hnic al risks: thre ate n the qual i ty and
timeliness of the software to be produced. If a
technical risk becomes a reality, implementation
may become difficult.
• Technical risks identify potential
— design
— Implementation
— interface,
— verification,
— maintenance problems.
• Technical risks occur because the problem is
harder to solve than you thought it would be.
Cont.
• Business risks: threaten the viability of the
software to be built and often jeopardize the
project or the product.
• Candidates for the top five business risks are
– building an excellent product or system that no one really
wants (market risk)
– building a product that no longer fits into the overall
business strategy for the company (strategic risk),
– building a product that the sales force doesn’t understand
how to sell (sales risk),
– losing the support of senior management due to a change in
focus or a change in people (management risk)
– losing budgetary or personnel commitment (budget risks).
Risk Management
• Risk Management provides
— Options, tradeoffs, effects, interactions
— Systematic view of the problem scope
— Contingency planning, action vs. reaction
— Active vs. passive management
— Feed forward, push vs. pull in design, planning and
execution
— Better, knowledgeable decision making
— Less exposure to risk
Risk Management Paradigm
Risk identification
• specify threats to the project plan (estimates,
schedule, resource loading, etc.).
— Generic risks are a potential threat to every software
project.
— Product-specific risks can be identified only by those
with a clear understanding of the technology, the
people, and the environment that is specific to the
software that is to be built.
Cont.
• One way for identifying risks is to create a risk
item checklist.
— Product size —Risks associated with the overall size
of the software to be built or modified.
— Business impact —Risks associated with constraints
imposed by management or the marketplace.
— Stakeholder characteristics —Risks associated with
the sophistication of the stakeholders and the
developer’s ability to communicate with stakeholders
in a timely manner.
Cont.
— Process definition —Risks associated with the degree
to which the software process has been defined and
is followed by the development organization.
— Development environment —Risks associated with
the availability and quality of the tools to be used to
build the product.
— Technology to be built —Risks associated with the
complexity of the system to be built and the
“newness” of the technology that is packaged by the
system.
— Staff size and experience —Risks associated with the
overall technical and project experience of the
software engineers who will do the work.
Risk Analysis
• Make a judgment about the probability and
seriousness of that risk.
— rely on our own judgment
— experience of previous projects
• assign the risk to one of a number of bands:
— The probability of the risk might be assessed as very
low ( 10%), low (10–25%), moderate (25–50%), high
(50–75%), or very high ( 75%).
— The effects of the risk might be assessed as
catastrophic (threaten the survival of the project),
serious (would cause major delays), tolerable (delays
are within allowed contingency), or insignificant.
Cont.
• Examples of different types of risks
Cont.
• Risk types and examples
Risk Planning
• considers each of the key risks that have been
identified, and develops strategies to manage
these risks.
• Avoidance strategies: the probability that the
risk will arise will be reduced.
• Minimization strategies: the impact of the risk
will be reduced.
• Contingency plans: that we are prepared for the
worst and have a strategy in place to deal with it.
Cont.
• Strategies to help manage risk
Risk Monitoring
• process of checking that your assumptions about the
product, process, and business risks have not changed.
Regularly assess each of the identified risks to decide
whether or not that risk is becoming more or less
probable.
Software Project Scheduling
Scheduling
• The Schedule connects the scope, work
estimates and deadline into a network of SE
tasks
• Must Manage:
— Parallelism (tasks can be undertaken
simultaneously)
— Dependency (task has an effect on subsequent tasks)
• Bad Scheduling is a very destructive influence
• 90-90 Rule: First 90% of a project is complete in
90% of the scheduled time. The other 10% is
also completed in 90% of the time
Two different perspectives of scheduling

— In the f ir st, an end date for release of a computer-

based system has already (and irrevocably) been
established.

— The second view of software scheduling assumes

t ha t r o ugh c hr o no l o gi c a l bo und s ha v e be e n
discussed but that the end date is set by the software
engineering organization.
Why Are Projects Late?
• An unrealistic deadline established by outsiders
• Changing customer requirements that are not
reflected in the schedule
• An honest underestimate of effort and/or
resources required
• Risks that were not considered when the project
started
• Technical and Human difficulties that could not have
been foreseen
• Miscommunication among project staff Project
management failing to recognize schedule
• slippage and not taking corrective action
Basic principle
• basic principles guide software project scheduling:
– Compartmentalization: project must be
compartmentalized into a number of manageable activities
and tasks. Both the product and the process are
decomposed.

– Interdependency: interdependency of each

compartmentalized activity or task must be determined.
Some tasks must occur in sequence, while others can occur
in parallel.

– Time allocation: each task to be scheduled must be

allocated some number of work units (e.g., person-days of
effort).
Cont.
– Effort validation. Every project has a defined number of
people on the software team.

– Defined responsibilities: every task that is scheduled should

be assigned to a specific team member.

– Defined outcomes: every task that is scheduled should have

a defined outcome.

– Defined milestones: every task or group of tasks should be

associated with a project milestone.
The project scheduling process
Tools and techniques for the planner
• Scheduling
— PERT – Program Evaluation and Review Technique
— Work Breakdown Structure (WBS)
— Gantt Chart – Named after Henry Grant
• ETVX – How do you track tasks
Program Evaluation and Review Technique
• (PERT) or Critical Path Method (CPM) is a
project scheduling method that determines:
– Critical Path (the chain of tasks that determine the duration
of the project)
– Earliest Time that a task can begin if all preceding tasks are
completed in the shortest possible time
– Latest Time for task initiation that will not delay the project
– Latest and Earliest Finish for the overall project
– Total Float (the maximum slippage without overall delay)
• Implementation:
— Automated tools
— Often use a task network as input
Cont.
• Define a Task Network
• Task (Activity) Network: a graphical representation of
the task flow and interdependencies for a project
WBS – Work break down structure
• What has to be done to complete the project
• All the tasks in the Divide and conquer of the
problem
• Granularity equals level of WBS
— First level, high level tasks
— Second level are those task that complete the first
level
Gantt chart
• A Gantt chart provides a graphical illustration of
a schedule that helps to plan, coordinate, and
track specific tasks in a project
— developed in 1917 by Henry L. Gantt
• A Gantt chart is constructed with a horizontal
axis representing the total time span of the
project, broken down into increments (for
example, days, weeks, or months) and a vertical
axis representing the tasks that make up the
project
Gantt chart
Resource Allocation
• Use list of resources
• WBS (Work Breakdown Structure)
— Tasks from estimation
— Development process being used
• Gantt charts
— Parallel tasking (Resource dependent)
• Pert charts
— Network of tasks
Tracking the Schedule
• Use list of Critical dates
• When do you need the resources
• When can you release the resources
• Actuals vs. Estimates
— Do you have to re-plan
— Are resources over committed
• Mythical Man-month
— Wall clock time vs. project time
— Trade $ for effort
Effort Allocation

• “front end” activities

— customer communication
— analysis
— design
— review and modification
• construction activities
— coding or code generation
• testing and installation
— unit, integration
— white-box, black box
— regression
Tracking
• The project schedule provides a roadmap for
tasks and milestones that must be tracked and
controlled as the project proceeds
• Tracking is based on the information provided
by the people completing the tasks
• The ability to track a project is only as good as
the data
Tracking
• Techniques:
— Hold Periodic project status meetings for all team
members
— Evaluate the results of all reviews
— Determine whether formal project milestones have
been accomplished by the scheduled date
— Comparing actual start date to planned start date for
each task
— Meeting informally with practitioners to obtain their
subjective assessment
— Using earned value analysis to assess progress
quantitatively