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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 1
Topics covered




Management activities
Project planning
Project scheduling
Risk management
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 2
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 3
Software management distinctions






The product is intangible
The product is uniquely flexible
The product is uniquely complex
Software engineering is not recognized as an
engineering discipline with the same status as
mechanical, electrical engineering, etc.
The software development process is not
standardised
Many software projects are “one-off” projects
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 4
Management activities






Proposal writing
Project planning and scheduling
Project costing
Project monitoring and reviews
Personnel selection and evaluation
Report writing and presentations
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 5
Project staffing

May not be possible to appoint the ideal people to
work on a project
•
•
•
Project budget may not allow for the use of highly-paid staff
Staff with the appropriate experience may not be available
An organisation may wish to develop employee skills on a
software project
• Here’s Bob. He’s a sophomore. He’ll be a member of your HazMat
Rover team. He doesn’t know much yet, but he can brew a mean cup
of coffee and has a great personality. 

Managers have to work within these constraints
•
especially when (as is currently the case) there is an international
shortage of skilled IT staff
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 6
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 7
Types of project plan
Plan
Quality plan
Validation plan
Configuration
management plan
Maintenance plan
Staff development plan.
©Ian Sommerville 2000
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.
Software Engineering, 6th edition. Chapter 4
Slide 8
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 9
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
Identify activity
dependencies
Estimate resources
for activities
Allocate people
to activities
Software
requirements
©Ian Sommerville 2000
Create project
charts
Activity charts
and bar charts
Software Engineering, 6th edition. Chapter 4
Slide 10
Scheduling problems


Estimating the difficulty of problems and
hence the cost of developing a solution is hard
Productivity is not proportional to the number
of people working on a task
•

Adding people to a late project makes it later because of
communication overheads
The unexpected always happens
•
Always allow contingency in planning
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 11
Bar charts and activity networks


Graphical notations used to illustrate the project
schedule
Show project breakdown into tasks
•
•


Tasks should not be too small
They should take about a week or two
Activity charts show task dependencies and the
the critical path
Bar charts show schedule against calendar time
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 12
Task durations and dependencies
Task
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
©Ian Sommerville 2000
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)
Software Engineering, 6th edition. Chapter 4
Slide 13
Activity network
8 days
15 days
M1
T3
15 days
T9
T1
25/7/99
4/7/99
start
14/7/99
5 days
4/8/99
25/8/99
T6
M4
M6
M3
7 days
20 days
15 days
T7
T2
25/7/99
10 days
M2
T4
T11
10 days
M7
T5
5/9/99
11/8/99
T10
18/7/99
M8
15 days
10 days
T12
M5
25 days
T8
Finish
19/9/99
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 14
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 15
Staff allocation
4/7
Fred
11/7
18/7
25/
1/8
8/8
15/8 22/8
29/8
5/9
12/9
19/9
T4
T8
T11
T12
Jane
T1
T3
T9
Anne
T2
T6
Jim
M ary
©Ian Sommerville 2000
T10
T7
T5
Software Engineering, 6th edition. Chapter 4
Slide 16
Risk management


Risk management is concerned with identifying
risks and drawing up plans to minimise their
effect on a project.
A risk is a probability that some adverse
circumstance will occur.
•
•
•
Project risks affect schedule or resources
Product risks affect the quality or performance of the software
being developed
Business risks affect the organisation developing or procuring
the software
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 17
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
©Ian Sommerville 2000
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.
Software Engineering, 6th edition. Chapter 4
Slide 18
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 19
Risk identification





Technology risks
People risks
Organisational risks
Requirements risks
Estimation risks
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 20
Risks and risk types
Risk type
Techno logy
People
Organ isationa l
Tools
Requi rements
Estim ation
©Ian Sommerville 2000
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.
Software Engineering, 6th edition. Chapter 4
Slide 21
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 22
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.
©Ian Sommerville 2000
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
Software Engineering, 6th edition. Chapter 4
Slide 23
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 24
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
©Ian Sommerville 2000
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.
Software Engineering, 6th edition. Chapter 4
Slide 25
Risk monitoring



Assess each identified risks regularly to decide
whether or not it is becoming less or more
probable
Also assess whether the effects of the risk have
changed
Each key risk should be discussed at management
progress meetings
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 26
Risk factors
Risk type
Techno logy
People
Organ isationa l
Tools
Requi rements
Estim ation
©Ian Sommerville 2000
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
Software Engineering, 6th edition. Chapter 4
Slide 27
Key points







Good project management is essential for project success
The intangible nature of software causes problems for management
Managers have diverse roles but their most significant activities are
planning, estimating and scheduling
Planning and estimating are iterative processes that continue
throughout the course of a project
A project milestone is a predictable state where
some formal report of progress is presented to management.
Risks may be project risks, product risks or business risks
Risk management is concerned with identifying risks that may affect
the project and planning to ensure that these risks do not develop
into major threats
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 28