Project management

● Organising, planning and 
scheduling software projects

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  1

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  2

Topics covered
● Management activities
● Project planning
● Project scheduling
● Risk management

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  3

Software project management
● Concerned with activities involved in ensuring 
that software is delivered on time and on 
schedule and in accordance with the 
requirements of the organisations developing 
and procuring the software
● Project management is needed because software 
development is always subject to budget and 
schedule constraints that are set by the 
organisation developing the software

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  4

Software management distinctions
● The product is intangible
● The product is uniquely flexible
● Software engineering is not recognized as an 
engineering discipline with the sane 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  5

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  6

Management commonalities
● These activities are not peculiar to software 
management
● Many techniques of engineering project 
management are equally applicable to software 
project management
● Technically complex engineering systems tend 
to suffer from the same problems as software 
systems

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  7

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
● 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  8

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
● 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  9

Types of project plan
Plan Description
Quality plan Describes the quality  procedures and
standards that will be used in a project.
Validation plan   Describes  the approach, resources and
schedule used for system validation.  
Configuration Describes  the configuration management
management plan procedures and structures to be used.
Maintenance plan Predicts the  maintenance requirements of
the system, maintenance costs and  effort
required.
Staff development plan. Describes how the skills and  experience of
the project team  members will be
developed.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  10

Project planning process
Establish the project constraints   
Make initial assessments of the project parameters   
Define project milestones and deliverables
while  project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to schedule
   Wait ( for a while )
   Review project progress
   Revise estimates of project parameters
   Update the project schedule
   Re­negotiate project constraints and deliverables
   if  ( problems arise ) then
     Initiate technical review and possible revision
   end if
end loop   

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  11

Project plan structure
● Introduction
● Project organisation
● Risk analysis
● Hardware and software resource requirements
● Work breakdown
● Project schedule
● Monitoring and reporting mechanisms

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  12

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
● The waterfall process allows for the 
straightforward definition of progress milestones

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  13

F
eF
aerastsu
ipib
lb
todrltyR
e q
aunirle
ym
s
i nt
s A
C
P
r
d
e
v T
o
l I
V
t T
I
E
S
y
p
e
m
n
t D
e
s
i
g
t
u
dn
y R
e
q
u
i
r
e
s
p
c
fm
n
t
s
a
i
o
Milestones in the RE process

yR
edqufirnem n
ttosME
v
aIrL
leu
tp
iEo
n
rS
T
O
N
E
S A
r
c
h
i
t
e
c
d
s
gu
r
a
l
n R
e
q
u
i
r
e
s
p
c
fm
n
t
s
a
i
o
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  14
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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  15

The project scheduling process

IreaS
d
e n
tqcuoifrvtew
im
faeyrsentsIdenptifyd aecntivesyE
stfiom
artec rivsoturcesA
lto catei vptopsleC
rA
eacntdacitv hb apyrrt oscjheacrtts
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  16
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  17

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  18

Task durations and dependencies
Task Duration (days) Dependencies
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  19
 8
 
d
Ta
y
s
1 21
4
/
5
/
77
M9
1
91
5
5
 d
T 
d
T
a6a
3
yy
ss 4
/
8
M 9
415
 
d
a
T
9ys
25
/
8
M
69
4/7st9ar15T M3 2
0  
d ay s 7 
day
s
Activity network

10 dT  
d
a
2ys
a4ys18M 25
//759M T
7
72910T
 d5ays1M /87915T
 
d
a
y
s T
15
M/
89
25T 0
 d8ays 19/9F10
 
d
a
ys
T12
insh
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  20
 4/7
118/7
25/7
/7
1/8
8/8
15/8
22/8
Start
T4
T1
T2
M1 29/
5/9
12
19
T7
Activity timeline

T3
M5
T8
M3
M2
T6
T5M4
T9
M7
T10
M6
T1
1 M8
T12F
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  21
/F 4
7
1
rJaeT/
7
1
d8
/
7
T
82
5
/1
/
88
/1
5
/
82
/
82
9
/
8
T
15
/
9
T
1
21
2
/
91
9
/
T
1ne
T
3
Staff allocation

Anne
Jim T
2T
7 T
6 T
9T
1
0
Mary T
5
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  22
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  23

Software risks
Risk Risk type Description
Staff turnover Project Experienced staff will leave the
project before it is finished.
Management change Project There will be a change of
organisational management with
different priorities.
Hardware unavailability Project Hardware which is essential for the
project will not be delivered on
schedule.
Requirements change Project and There will be a larger number of
product changes to the requirements than
anticipated.
Specification delays Project and Specifications of essential interfaces
product are not available on schedule
Size underestimate Project and The size of the system has been
product underestimated.
CASE tool under­ Product CASE tools which support the
performance project do not perform as anticipated
Technology change Business The underlying technology on which
the system is built is superseded by
new technology.
Product competition Business A competitive product is marketed
before the system is completed.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  24
The risk management process
● Risk identification
• Identify project, product and business risks
● Risk analysis
• Assess the likelihood and consequences of these risks
● Risk planning
• Draw up plans to avoid or minimise the effects of the risk
● Risk monitoring
• Monitor the risks throughout the project

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  25

iL R sk R
iisdte onrtfisfpkoctaetnioinalPisk
 a n ly si R is k  p la n i g m oR
i
ns
tk
orng
The risk management process

riotlised riskaR
indskc panvltoisdganceyaseR
ism
kent
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  26
Risk identification
● Technology risks
● People risks
● Organisational risks
● Requirements risks
● Estimation risks

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  27

Risks and risk types
Risk type Possible risks
Technology The database used in the system cannot process as many
transactions per second as expected.
Software components which should be reused contain defects
which limit their functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different management
are responsible for the project.
Organisational financial problems force reductions in the project
budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements which require major design rework are
proposed.
Customers fail to understand the impact of requirements
changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  28

Risk analysis
● Assess probability and seriousness of each risk
● Probability may be very low, low, moderate, high 
or very high
● Risk effects might be catastrophic, serious, 
tolerable or insignificant

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  29

Risk analysis
Risk Probability Effects
Organisational financial problems force reductions Low Catastrophic
in the project budget.
It is impossible to recruit staff with the skills High Catastrophic
required for the project.
Key staff are ill  at critical times in the project. Moderate Serious
Software components which should be reused Moderate Serious
contain defects which limit their functionality.
Changes to requirements which require major Moderate Serious
design rework are proposed.
The organisation is restructured so that different High Serious
management are responsible for the project.
The database used in the system cannot process as Moderate Serious
many transactions per second as expected.
The time required to develop the software is High Serious
underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of Moderate Tolerable
requirements changes.
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  30

Risk planning
● Consider each risk and develop a strategy to 
manage that risk
● Avoidance strategies
• The probability that the risk will arise is reduced
● Minimisation strategies
• 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  31

Risk management strategies
Risk Strategy
Organisational Prepare a briefing document for senior management showing
financial problems how the project is making a very important contribution to the
goals of the business.
Recruitment Alert customer of potential difficulties and the possibility of
problems delays, investigate buying­in components.
Staff illness Reorganise team so that there is more overlap of work and
people therefore understand each otherÕs jobs.
Defective Replace potentially defective components with bought­in
components components of known reliability.
Requirements Derive traceability information to assess requirements change
changes impact, maximise information hiding in the design.
Organisational Prepare a briefing document for senior management showing
restructuring how the project is making a very important contribution to the
goals of the business.
Database Investigate the possibility of buying a higher­performance
performance database.
Underestimated Investigate buying in components, investigate use of a program
development time generator.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  32

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  33

Risk factors
Risk type Potential indicators
Technology Late delivery of hardware or support software, many
reported technology problems
People Poor staff morale, poor relationships amongst team
member, job availability
Organisational organisational gossip, lack of action by senior
management
Tools reluctance by team members to use tools, complaints
about CASE tools, demands for higher­powered
workstations
Requirements many requirements change requests, customer
complaints
Estimation failure to meet agreed schedule, failure to clear
reported defects

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  34

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 
which continue throughout the course of a 
project
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4  Slide  35
Key points
● 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 which 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  36