Download Project management

Project management


Organising, planning and scheduling software
projects
Objectives
•
•
•
•
To introduce software project management and to
describe its distinctive characteristics
To discuss project planning and the planning process
To show how graphical schedule representations are
used by project management
To discuss the notion of risks and the risk management
process
Terminology

Milestones
•
•
•
•
Have a duration of zero
Identify critical points in your schedule
Shown as inverted triangle or a diamond
Often used at “review” or “delivery” times
• Or at end or beginning of phases
• Ex: Software Requirements Review (SRR)
• Ex: User Sign-off
•
Can be tied to contract terms
Terminology
Example
Milestones
Waterfall Model: Analysis Phase
I1:Open
A.I1:Open
I2:Open
I3:Open
A.I2:Open
SD.I1:Open
Analysis
Analysis
SD.I3:Open
SD.I2:Open
Waterfall Model: Design Phase
I1:Closed
A.I1:Open
I2:Closed
I3:Open
A.I2:Open
SD.I1:Open
Analysis
Analysis
SD.I3:Open
SD.I2:Open
Design
Waterfall Model: Implementation
Phase
I1:Closed
A.I1:Closed
I2:Closed
I3:Closed
A.I2:Closed
SD.I1:Open
Analysis
SD.I3:Open
SD.I2:Open
Design
Implementation
Waterfall Model: Project is Done
I1:Closed
A.I1:Closed
I2:Closed
I3:Closed
A.I2:Closed
SD.I1:Open
Analysis
SD.I3:Open
SD.I2:Open
Design
Implementation
Issue-Based Model: Analysis
Phase
I1:Open
A.I1:Open
I2:Open
I3:Open
A.I2:Open
Analysis:80
%
SD.I1:Open
SD.I3:Open
Design:
10%
Implementation: 10%
SD.I2:Open
Issue-Based Model: Design
Phase
I1:Closed
A.I1:Open
I2:Closed
I3:Open
A.I2:Open
Analysis:40
%
SD.I1:Open
SD.I3:Open
Design:
60%
Implementation: 0%
SD.I2:Open
Issue-Based Model:
Implementation Phase
I1:Open
A.I1:Open
I2:Closed
I3:Closed
A.I2:Closed
Analysis:10
%
SD.I1:Open
SD.I3:Open
Design:
10%
Implementation: 60%
SD.I2:Cosed
Issue-Based Model: Project is
Done
I1:Closed
A.I1:Closed
I2:Closed
I3:Closed
A.I2:Closed
Analysis:0
%
SD.I1:Closed
SD.I3:Closed
Design: 0%
Implementation: 0%
SD.I2:Closed
Software project management

Concerned with activities involved in ensuring
that software is delivered
•
•
•

on time
within the budget
in accordance with the requirements
Project management is needed because software
development is always subject to budget and
schedule constraints
•
Set by the development organisation or the customer
Project staffing


May not be possible to appoint the ideal people to
work on a project
Managers have to work within these constraints
•
especially when (as is currently the case) there is an international
shortage of skilled IT staff
Project planning



Probably the most time-consuming project management
activity
Continuous activity from initial concept through
to system delivery
Plans must be regularly revised as new information
becomes available
•

Beware of grumbling developers
Various different types of plan may be developed to
support the main software project plan that is concerned
with schedule and budget
Types of project plan
Plan
Quality plan
Validation plan
Configuration
management plan
Maintenance plan
Staff development plan.
Des cription
Des cribes the quality
procedures and
s tandards that will be us ed in a project.
Des cribes the approach, resources and
s chedule used for sys tem validation.
Des cribes the configuration management
procedures and structures to be us ed.
Predicts the maintenance requirements of
the s ystem, maintenance cos ts and
effort
required.
Des cribes how the skills and experience of
the project team
members will be
developed.
Activity organization



Activities in a project should be organised to produce
tangible outputs for management to judge progress
Milestones are the end-point of a process activity
Deliverables are project results delivered to customers
ACT IVITIES
Feasibility
study
Requir ements
analysis
Prototype
development
Design
study
Requir ements
specification
Feasibility
report
Requir ements
definition
Evaluation
report
Architectural
design
Requir ements
specification
MILESTONES
Project scheduling




Split project into tasks and estimate time and resources
required to complete each task
Organize tasks concurrently to make optimal use of
workforce
Minimize task dependencies to avoid delays
caused by one task waiting for another to complete
Dependent on project managers’ intuition and experience
Identify
activities
Software
requirements
Identify activity
dependencies
Estimate resources
for activities
Allocate people
to activities
Create project
charts
Activity charts
and bar charts
Task durations and dependencies
Task
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
Duration (da ys)
8
15
15
10
10
5
20
25
15
15
7
10
Dependencies
T1 (M1)
T2, T4 (M2)
T1, T2 (M3)
T1 (M1)
T4 (M5)
T3, T6 (M4)
T5, T7 (M7)
T9 (M6)
T11 (M8)
Activity timeline – Gantt chart
4/ 7
11/ 7
18 /7
25 /7
1/ 8
8/ 8
15 /8
22 /8
29 /8
5/ 9
12 /9
19 /9
St art
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T 10
M6
T 11
M8
T 12
Fi nish
MS-Project Example
Staff allocation
4/7
Fred
11/7
18/7
25/
1/8
8/8
15/8 22/8
29/8
5/9
T4
T8
T11
T12
Jane
T1
T3
T9
Anne
T2
T6
Jim
M ary
T7
T5
T10
12/9
19/9
Software risks
Risk
Staff turnover
Risk type
Project
Management change
Project
Hardware unavailability
Project
Requirements change
Project and
product
Specification delays
Project and
product
Project and
product
Product
Size underestimate
CASE t ool underperformance
Technology change
Product comp etition
Business
Business
Description
Experienced staff will leave the
project before it is finished.
There will be a change of
organisational management with
different priorities.
Hardware which is essential for the
project will not be delivered on
schedule.
There will be a larger numb er of
changes to the requirements than
anticipated.
Specifications of essential interfaces
are not available on schedule
The size of the system has been
underestimated.
CASE t ools which support the
project do not perform as anticipated
The underlying technology on which
the system is b uilt is superseded by
new technology.
A competitive product is marketed
before the system is completed.
PERT


Program Evaluation and Review Technique
Based on idea that estimates are uncertain
•
•


Therefore uses duration ranges
And the probability of falling to a given range
Uses an “expected value” (or weighted average) to
determine durations
Use the following methods to calculate the expected
durations, then use as input to your network diagram
PERT

Start with 3 estimates
•
Optimistic
• Would likely occur 1 time in 20
•
Most likely
• Modal value of the distribution
•
Pessimistic
• Would be exceeded only one time in 20
PERT Formula

Combined to estimate a task duration
PERT Formula


Confidence Interval can be determined
Based on a standard deviation of the expected
time
• Using a bell curve (normal distribution)

For the whole critical path use
PERT Example


Description
Planner 1
Planner 2
m
10d
10d
a
9d
9d
b
12d
20d
PERT time
10.16d
11.5d
Std. Dev.
0.5d
1.8d
Confidence interval for P2 is 4 times wider than P1 for a given probability
Ex: 68% probability of 9.7 to 11.7 days (P1) vs. 9.5-13.5 days (P2)
PERT

Advantages
•

Disadvantages
•
•
•
•

Accounts for uncertainty
Time and labor intensive
Assumption of unlimited resources is big issue
Lack of functional ownership of estimates
Mostly only used on large, complex project
Get PERT software to calculate it for you
The risk management process




Risk identification – Identify project, product and business risks
Risk analysis – Assess the likelihood and consequences of risks
Risk planning – Draw up plans to avoid/minimise risk effects
Risk monitoring – Monitor the risks throughout the project
Risk
identification
Risk analysis
Risk planning
Risk
monitoring
List of potential
risks
Prioritised risk
list
Risk avoidance
and contingency
plans
Risk
assessment
Risk identification





Technology risks
People risks
Organisational risks
Requirements risks
Estimation risks
Risks and risk types
Risk type
Techno logy
People
Organ isationa l
Tools
Requi rements
Estim ation
Possibl e risks
The da tabase used in the system canno t process as many
transa ctions per second as exp ected.
Software componen ts which shou ld be reused cont ain de fects
which limit their fun ction alit y.
It is im possible to recruit staff wit h the skill s required.
Key staff are ill and unava il able at criti cal tim es.
Requi red training for staff is not availa ble.
The o rgan isation is restructured so that diff erent manag ement
are respons ible for the project.
Organ isationa l f inancial problems force reduc tions in the project
budge t.
The cod e gen erated by CASE tools is i neffi cient.
CASE tools canno t be integrated.
Changes to requirements which requir e major design rework are
proposed .
Customers fail to unde rstand the im pact of requirements
chang es.
The tim e requir ed to deve lop the software is unde restim ated.
The rate of defect repair is und erestim ated.
The size o f t he software is unde restim ated.
Risk analysis


Assess probability and seriousness of each risk
Probability may be
•
•
•
•
•

very low
low
moderate
high
very high
Risk effects might be
•
•
•
•
catastrophic
serious
tolerable
insignificant
Risk analysis
Risk
Organ isationa l f inancial problems force reduc tions
in the project budge t.
It is im possible to recruit staff wit h the skill s
required for the p roject.
Key staff are ill at crit ical tim es in the project.
Software componen ts which shou ld be reused
contain defects which limit their func tiona lit y.
Changes to requirements which requir e major
design rewo rk are proposed.
The o rgan isation is restructured so that diff erent
manage me nt are respons ible for the project.
The da tabase used in the system canno t process as
many transactions per second as expec ted.
The tim e requir ed to deve lop the software is
unde restim ated.
CASE tools canno t be integrated.
Customers fail to unde rstand the im pact of
requirements change s.
Requi red training for staff is not availa ble.
The rate of defect repair is und erestim ated.
The size o f t he software is unde restim ated.
The cod e gen erated by CASE tools is i neffi cient.
Probability Effects
Low
Catastrophic
High
Catastrophic
Moderate
Moderate
Serious
Serious
Moderate
Serious
High
Serious
Moderate
Serious
High
Serious
High
Moderate
Tolerable
Tolerable
Moderate
Moderate
High
Moderate
Tolerable
Tolerable
Tolerable
Insignif icant
Risk planning


Consider each risk and develop a strategy to
manage that risk
Avoidance strategies
•

Minimisation strategies
•

The probability that the risk will arise is reduced
The impact of the risk on the project or product will be reduced
Contingency plans
•
If the risk arises, contingency plans are plans to deal with that
risk
Risk planning strategies
Risk
Organ isationa l
financ ial problems
Recruitm ent
problems
Staff illness
Defective
componen ts
Requi rements
chang es
Organ isationa l
restructuring
Database
performanc e
Unde restim ated
deve lopment time
Strategy
Prepare a briefing document for senior manage ment show ing
how the p roject is making a very im portant contribu tion to the
goa ls of the bus iness.
Alert customer of potential difficulti es and the possibil ity of
delays, inves tigate buying- in componen ts.
Reorgan is e team so that there is more ove rlap of work and
people therefo re unde rstand each other ’s jobs.
Replace pot entia lly defective componen ts wit h bough t-in
componen ts of known reli abilit y.
Derive traceabili ty info rmation to assess requ ir ements chang e
im pact, maximi se information hid ing in the design.
Prepare a briefing document for senior manage ment show ing
how the p roject is making a very im portant contribu tion to the
goa ls of the bus iness.
Inves tigate the po ssibilit y o f buy ing a high er-performanc e
database.
Inves tigate buying in componen ts, inve stigate use of a program
gene rator.
Risk factors
Risk type
Techno logy
People
Organ isationa l
Tools
Requi rements
Estim ation
Potential indi cators
Late delivery of hardware or support software, many
reported techno logy problems
Poor staff morale, poor relationsh ips amongst team
member, job availa bilit y
organ isationa l gos sip, lack of action by senior
manage me nt
reluctance by team members to use tools , complaints
about CASE tools, demand s for highe r-powered
workstations
many requir ements chang e reque sts, customer
complaints
fail ure to meet agreed schedul e, failure to clear
reported defects