18CSE032T - Software Project

Management

UNIT 1 - PROJECT EVALUATION AND

PROJECT PLANNING
 UNIT 1 - PROJECT EVALUATION AND PROJECT
PLANNING (SYLLABUS)

Importance of Software Project Management -

Activities Methodologies - Categorization of
Software Projects - Setting objectives -
Management Principles - Management Control -
Project Portfolio Management - Cost-Benefit
Evaluation Technology - Risk Evaluation -
Strategic Program Management - Stepwise
Project Planning.
 Introduction &
Importance of Software
Project Management
 Outline of talk
In this introduction the main questions to be
addressed will be:
– What is software project management? Is it really
different from ‘ordinary’ project management?
– How do you know when a project has been
successful? For example, do the expectations of
the customer/client match those of the
developers?

4
 Why is project management important?

• Large amounts of money are spent on ICT(Information

Communication Technology) e.g. UK government in 2003-4
spent £2.3 billions on contracts for ICT and only £1.4 billions
on road building
• Project often fail – Standish Group(The Standish Group is a
primary research advisory organization that focuses on
software development performance) claim only a third of ICT
projects are successful. 82% were late and 43% exceeded
their budget.
• Poor project management a major factor in these failures

5
 What is a project?
Some dictionary definitions:
“A specific plan or design”
“A planned undertaking”
“A large undertaking e.g. a public works
scheme”
Longmans dictionary
Key points above are planning and size of task

6
 Jobs versus projects

 ‘Jobs’ – repetition of very well-defined and well

understood tasks with very little uncertainty
 ‘Exploration’ – e.g. finding a cure for cancer: the
outcome is very uncertain
 Projects – in the middle!
 Characteristics of projects
A task is more ‘project-like’ if it is:
• Non-routine
• Planned
• Aiming at a specific target
• Carried out for a customer
• Carried out by a temporary work group
• Involving several specialisms
• Made up of several different phases
• Constrained by time and resources
• Large and/or complex

8
Are software projects really different from other
projects?
Not really …but

• Invisibility
• Complexity
• Conformity
• Flexibility
make software more problematic to build
than other engineered artefacts.

9
 Contract management versus technical project
management
Projects can be:
• In-house: clients and developers are
employed by the same organization
• Out-sourced: clients and developers
employed by different organizations
• ‘Project manager’ could be:
– a ‘contract manager’ in the client organization
– a technical project manager in the
supplier/services organization

11
 Software Project Management (SPM)
• Software Project Management (SPM) is a sub-field of Project
Management in which software projects are planned,
implemented, monitored and controlled.
• It consists of 3 terms: Software, Project and Management.
 Software- a set of programs, documentation and user manual
for a particular software project. So, it is basically the
complete procedure of the software development starting
from the requirement gathering phase and extending to
testing and maintenance.
 Project means a planned activity which consists of several
well defined tasks.
 Management makes sure that the product comes out as
planned.
There are many constraints of the software projects but the
main and fundamental constraints includes: Time, Cost and
Quality. Any one of the two factors can severely affect the third
one.
Therefore, Software Project Management is essential to develop
software projects within time and the specified budget and that
too of good quality.
Software Project Manager:
Software Project Manager is generally never directly involved in
producing the end product but he controls and manages the
activities involved in the production. He is aware of all the
phases of Software Development Life Cycle that the software
would go through.
Responsibilities of software project manager:
• Managing people:
– Acts as a project leader
– Communication with stakeholders
– Manages human resources
• Managing project:
– Monitors progress and performance
– Risk analysis at every phase
– Manages time and budget constraint
Software Project Management

Activities Methodologies
 Activities covered by project management

Feasibility study
Is project technically feasible and worthwhile from a business point
of view?
Planning
Only done if project is feasible
Execution
Implement plan, but plan may be changed as we go along

16
The software development life-cycle (ISO 12207)
 ISO 12207 life-cycle
• Requirements analysis
– Requirements elicitation: what does the client
need?
– Analysis: converting ‘customer-facing’
requirements into equivalents that developers can
understand
– Requirements will cover
• Functions
• Quality
• Resource constraints i.e. costs

18
 ISO 12207 life-cycle
• Architecture design
– Based on system requirements
– Defines components of system: hardware,
software, organizational
– Software requirements will come out of this
• Code and test
– Of individual components
• Integration
– Putting the components together

19
 ISO12207 continued
• Qualification testing
– Testing the system (not just the software)
• Installation
– The process of making the system operational
– Includes setting up standing data, setting system
parameters, installing on operational hardware
platforms, user training etc
• Acceptance support
– Including maintenance and enhancement

20
 Plans, methods and methodologies

Methodology = a set of methods

Context

Plan
Methods
+ start and end dates for each activity,
A way of working staffing, tools and materials etc

21
Categorization of Software Projects
 Some ways of categorizing projects

Distinguishing different types of project is important as

different types of task need different project
approaches e.g.
• Voluntary systems (such as computer games) versus
compulsory systems e.g. the order processing system
in an organization
• Information systems versus embedded systems
• Objective-based versus product-based
• Product-development versus outsourced

24
1. Compulsory Vs Voluntary systems (projects):

– Compulsory systems are the systems which

the staff of an organization have to use if
they want to do a task.
– Voluntary systems are the systems which are
voluntarily used by the users e.g.. computer
gaming, school project, etc.
 2. Information Vs Embedded systems (projects):

• Information systems are used by staff to

carry out office processes and tasks eg.
stock control system.
• Embedded systems are used to control
machines eg. a system controlling
equipment in a building.
 3. Objective-based Vs Product-based systems
(projects):
• Project whose requirement is to meet
certain objectives which could be met in a
number of ways, is objective-based project.
• Project whose requirement is to create a
product, the details of which have been
specified by the client, is product-based
project.
Setting objectives
 Stakeholders
These are people who have a stake or interest in the
project
In general, they could be users/clients or
developers/implementers
They could be:
• Within the project team
• Outside the project team, but within the same
organization
• Outside both the project team and the organization

Different stakeholders may have different objectives –

need to define common project objectives
30
 Setting objectives
• Answering the question ‘What do we have to
do to have a success?’
• Need for a project authority
– Sets the project scope
– Allocates/approves costs
• Could be one person - or a group
– Project Board
– Project Management Board
– Steering committee

31
 Objectives
Informally, the objective of a project can be
defined by completing the statement:
The project will be regarded as a success
if……….
…………
Rather like post-conditions for the project
Focus on what will be put in place, rather than
how activities will be carried out
32
 Objectives should be SMART
S – specific, that is, concrete and well-defined
M – measurable, that is, satisfaction of the objective
can be objectively judged
A – achievable, that is, it is within the power of the
individual or group concerned to meet the target
R – relevant, the objective must relevant to the true
purpose of the project
T – time constrained: there is defined point in time by
which the objective should be achieved

33
 Goals/sub-objectives
These are steps along the way to achieving the
objective
Informally, these can be defined by completing
the sentence
To reach objective X, the following must be in
place
A……………
B……………
C…………… etc

34
 Goals/sub-objectives continued
Often a goal can be allocated to an individual
Individual might have the capability of achieving
goal on their own, but not the overall
objective e.g.
Overall objective – user satisfaction with
software product
Analyst goal – accurate requirements
Developer goal – reliable software

35
 Measures of effectiveness
How do we know that the goal or objective has
been achieved?
By a practical test, that can be objectively
assessed.
e.g. for user satisfaction with software product:
• Repeat business – they buy further products
from us
• Number of complaints – if low etc etc

36
 The business case

Benefits Benefits of delivered

project must
Costs outweigh costs
Costs include:
- Development
£ - Operation
£
Benefits
Quantifiable
Non-quantifiable
37
 Project success/failure
• Degree to which objectives are met
scope (of deliverables)

time cost

In general if, for example, project is running out of time,

this can be recovered for by reducing scope or increasing
costs. Similarly costs and scope can be protected by
adjusting other corners of the ‘project triangle’.

38
 Other success criteria
These can relate to longer term, less directly
tangible assets
• Improved skill and knowledge
• Creation of assets that can be used on future
projects e.g. software libraries
• Improved customer relationships that lead to
repeat business

39
Management Principles
 What is management?
This involves the following activities:
• Planning – deciding what is to be done
• Organizing – making arrangements
• Staffing – selecting the right people for the job
• Directing – giving instructions
continued…

41
 What is management?
(continued)
• Monitoring – checking on progress
• Controlling – taking action to remedy hold-ups
• Innovating – coming up with solutions when
problems emerge
• Representing – liaising with clients, users,
developers and other stakeholders

42
 Project Planning
• Carried out before development starts.
• Important activities:
– Estimation
– Scheduling
– Staffing
– Risk management
– Miscellaneous plans

43
 Traditional versus Modern Project
Management
• Projects are increasingly being based on
either tailoring some existing product or
reusing certain pre-built libraries.
• Facilitating and accommodating client
feedbacks
• Facilitating customer participation in project
development work
• Incremental delivery of the product with
evolving functionalities.
44
Management control
Management control

49
 Management control
Data – the raw details
e.g. ‘6,000 documents processed at location X’
Information – the data is processed to produce something that is meaningful
and useful
e.g. ‘productivity is 100 documents a day’
Comparison with objectives/goals
e.g. we will not meet target of processing all documents by 31st March
continued…..

50
 Management control - continued
Modelling – working out the probable outcomes
of various decisions
e.g. if we employ two more staff at location X how
quickly can we get the documents processed?
Implementation – carrying out the remedial
actions that have been decided upon

51
Project Portfolio Management
 The business case
• Feasibility studies can also act as a ‘business
case’
• Provides a justification for starting the project
• Should show that the benefits of the project
will exceed development, implementation and
operational costs
• Needs to take account of business risks

53
 Contents of a business case
1. Introduction/ background 5. The benefits
2. The proposed project 6. Outline implementation plan
3. The market 7. Costs
4. Organizational and 8. The financial case
operational infrastructure 9. Risks
10. Management plan

54
 Content of the business case
• Introduction/background: describes a
problem to be solved or an opportunity to be
exploited
• The proposed project: a brief outline of the
project scope
• The market: the project could be to develop a
new product (e.g. a new computer game). The
likely demand for the product would need to
be assessed.

55
 Content of the business case - continued

• Organizational and operational

infrastructure: How the organization would
need to change. This would be important
where a new information system application
was being introduced.
• Benefits These should be express in financial
terms where possible. In the end it is up to the
client to assess these – as they are going to
pay for the project.

56
 Content of the business case - continued

• Outline implementation plan: how the

project is going to be implemented. This
should consider the disruption to an
organization that a project might cause.
• Costs: the implementation plan will supply
information to establish these
• Financial analysis: combines costs and benefit
data to establish value of project

57
 Project portfolio management
The concerns of project portfolio management
include:
• Evaluating proposals for projects
• Assessing the risk involved with projects
• Deciding how to share resources between
projects
• Taking account of dependencies between
projects
• Removing duplication between projects
• Checking for gaps
58
 Project portfolio management - continued

There are three elements to PPM:

1. Project portfolio definition
– Create a central record of all projects within an
organization
– Must decide whether to have ALL projects in the
repository or, say, only ICT projects
– Note difference between new product
development (NPD) projects and renewal
projects e.g. for process improvement

59
 Project portfolio management - continued
2. Project portfolio management
Actual costing and performance of projects can be recorded
and assessed
3. Project portfolio optimization
The performance of the portfolio can be tracked by high-
level managers on a regular basis.
Information gathered above can be used achieve better
balance of projects e.g. some that are risky but potentially
very valuable balanced by less risky but less valuable
projects
You may want to allow some work to be done outside the
portfolio e.g. quick fixes
60
Cost benefit analysis (CBA) and Risk
evaluation
 Cost benefit analysis (CBA)
This relates to an individual project. You need to:
• Identify all the costs which could be:
– Development costs
– Set-up costs
– Operational costs
• Identify the value of benefits
• Check benefits are greater than costs

62
 Product/system life cycle cash flows

• The timing of the costs and income for a product of system needs to be
estimated.
• The development of the project will incur costs.
• When the system or product is released it will generate income that
gradually pays off costs
• Some costs may relate to decommissioning – think of demolishing a
nuclear power station.

63
 Net profit
Year Cash-flow ‘Year 0’ represents all the costs
before system is in operation
0 -100,000
‘Cash-flow’ is value of income less
1 10,000 outgoing
Net profit is the value of all the cash-
2 10,000 flows for the lifetime of the
application
3 10,000

4 20,000

5 100,000

Net profit 50,000

66
 Pay back period
The payback period is the time taken to break even or pay back the initial
investment.

Year Cash-flow Accumulated

0 -100,000 -100,000

1 10,000 -90,000

2 10,000 -80,000

3 10,000 -70,000

4 20,000 -50,000

5 100,000 50,000

68
Return on investment (ROI)

71
 Net present value
Would you rather I gave you £100 today or in 12
months time?
If I gave you £100 now you could put it in savings
account and get interest on it.
If the interest rate was 10% how much would I
have to invest now to get £100 in a year’s
time?
This figure is the net present value of £100 in
one year’s time
73
 Discount factor
Discount factor = 1/(1+r)t
r is the interest rate (e.g. 10% is 0.10)
t is the number of years
In the case of 10% rate and one year
Discount factor = 1/(1+0.10) = 0.9091
In the case of 10% rate and two years
Discount factor = 1/(1.10 x 1.10) =0.8294

74
 Applying discount factors
Year Cash-flow Discount factor Discounted cash flow

0 -100,000 1.0000 -100,000

1 10,000 0.9091 9,091
2 10,000 0.8264 8,264
3 10,000 0.7513 7,513
4 20,000 0.6830 13,660

5 100,000 0.6209 62,090

NPV 618

75
 Internal rate of return
• Internal rate of return (IRR) is the discount
rate that would produce an NPV of 0 for the
project
• Can be used to compare different investment
opportunities
• There is a Microsoft Excel function which can
be used to calculate

76
 Dealing with uncertainty: Risk evaluation

• project A might appear to give a better return

than B but could be riskier
• Could draw up draw a project risk matrix for
each project to assess risks – see next
overhead
• For riskier projects could use higher discount
rates

78
Example of a project risk matrix

79
Decision trees

84
Strategic program Management
 Programme management
• One definition:
‘a group of projects that are managed in a co-
ordinated way to gain benefits that would not
be possible were the projects to be managed
independently’ Ferns

87
 Programmes may be
• Strategic
• Business cycle programmes
• Infrastructure programmes
• Research and development programmes
• Innovative partnerships

88
Programme managers versus project managers

Programme manager Project manager

– Many simultaneous – One project at a time
projects – Impersonal
– Personal relationship relationship with
with skilled resources resources
– Optimization of – Minimization of
resource use demand for resources
– Projects tend to be – Projects tend to be
seen as similar seen as unique

89
 Strategic programmes
• Based on OGC (Open Geospatial Consortium)
approach
• Initial planning document is the Programme
Mandate describing
– The new services/capabilities that the programme
should deliver
– How an organization will be improved
– Fit with existing organizational goals
• A programme director appointed a champion
for the scheme

90
 Next stages/documents
• The programme brief – equivalent of a
feasibility study: emphasis on costs and
benefits
• The vision statement – explains the new
capability that the organization will have
• The blueprint – explains the changes to be
made to obtain the new capability

91
 Benefits management
developers users organization

use for

the
benefits
application
build to deliver

•Providing an organization with a capability and does not guarantee

that this will provide benefits envisaged – need for benefits
management
•This has to be outside the project
• Therefore done at programme level

92
 Benefits management
To carry this out, you must:
• Define expected benefits
• Analyse balance between costs and benefits
• Plan how benefits will be achieved
• Allocate responsibilities for their achievement
• Monitor achievement of benefits

93
 Benefits
These might include:
• Mandatory requirement
• Improved quality of service
• Increased productivity
• More motivated workforce
• Internal management benefits

94
 Benefits - continued
• Risk reduction
• Economies
• Revenue enhancement/acceleration
• Strategic fit

95
 Quantifying benefits
Benefits can be:
• Quantified and valued e.g. a reduction of x
staff saving £y
• Quantified but not valued e.g. a decrease in
customer complaints by x%
• Identified but not easily quantified – e.g.
public approval for a organization in the
locality where it is based

96
Stepwise Project Planning
 ‘Step Wise’ - an overview
0.Select
1. Identify project 2. Identify project
project objectives infrastructure

3. Analyse
project
characteristics

Review 4. Identify products

and activities
Lower
level 5. Estimate effort
detail for activity For each
activity
6. Identify activity
risks
10. Lower level
7. Allocate
planning
resources

8. Review/ publicize
9. Execute plan plan
98
 A project scenario: Brightmouth College
Payroll

• College currently has payroll processing

carried out by a services company
• This is very expensive and does not allow
detailed analysis of personnel data to be
carried out
• Decision made to bring payroll ‘in-house’ by
acquiring an ‘off-the-shelf’ application

99
 Project scenario - continued
• The use of the off-the-shelf system will require
a new, internal, payroll office to be set up
• There will be a need to develop some
software ‘add-ons’: one will take payroll data
and combine it with time-table data to
calculate the staff costs for each course run in
the college
• The project manager is Brigette.

100
 Step 1 establish project scope and
objectives
• 1.1 Identify objectives and measures of
effectiveness
– ‘how do we know if we have succeeded?’
• 1.2 Establish a project authority
– ‘who is the boss?’
• 1.3 Identify all stakeholders in the project and
their interests
– ‘who will be affected/involved in the project?’

101
 Step 1 continued
• 1.4 Modify objectives in the light of
stakeholder analysis
– ‘do we need to do things to win over
stakeholders?’
• 1.5 Establish methods of communication with
all parties
– ‘how do we keep in contact?’

102
 Step 2 Establish project infrastructure
• 2.1 Establish link between project and any
strategic plan
– ‘why did they want the project?’
• 2.2 Identify installation standards and
procedures
– ‘what standards do we have to follow?’
• 2.3. Identify project team organization
– ‘where do I fit in?’

103
 Step 3 Analysis of project
characteristics
• 3.1 Distinguish the project as either objective
or product-based.
– Is there more than one way of achieving success?
• 3.2 Analyse other project characteristics
(including quality based ones)
– what is different about this project?

104
 Step 3 continued
• Identify high level project risks
– ‘what could go wrong?’
– ‘what can we do to stop it?’
• Take into account user requirements
concerning implementation
• Select general life cycle approach
– waterfall? Increments? Prototypes?
• Review overall resource estimates
– ‘does all this increase the cost?’

105
 Step 4 Identify project products and
activities
• 4.1 Identify and describe project products - ‘what do we have to
produce?’

106
 Products
• The result of an activity
• Could be (among other things)
– physical thing (‘installed pc’),
– a document (‘logical data structure’)
– a person (‘trained user’)
– a new version of an old product (‘updated
software’)

107
 Products
• The following are NOT normally products:
– activities (e.g. ‘training’)
– events (e.g. ‘interviews completed’)
– resources and actors (e.g. ‘software developer’) -
may be exceptions to this
• Products CAN BE deliverable or intermediate

108
 Product description (PD)
• Product identity • Relevant standards
• Description - what is it? • Quality criteria
• Derivation - what is it based
on?
• Composition - what does it Create a PD for ‘test data’
contain?
• Format

109
 Step 4 continued
• 4.2 document generic product flows

110
 Step 4.3 Recognize product instances

• The PBS (Product Breakdown Structure) and

PFD(Product flow diagram) will probably have
identified generic products e.g. ‘software
modules’
• It might be possible to identify specific
instances e.g. ‘module A’, ‘module B’ …
• But in many cases this will have to be left to
later, more detailed, planning

111
 4.4. Produce ideal activity network
• Identify the activities needed to create each
product in the PFD
• More than one activity might be needed to
create a single product
• Hint: Identify activities by verb + noun but
avoid ‘produce…’ (too vague)
• Draw up activity network

112
 An ‘ideal’ activity

113
 Step 4.5 Add check-points if needed
Design Code
module A module A

Design Design Code

system Test
module B module B system

Design Code put in a

module C module C
check point

Design Code
module A module A

Design Design Code

system Check-point Test
module B module B system

Design Code
module C module C
114
 Step 5:Estimate effort for each
activity
• 5.1 Carry out bottom-up estimates
– distinguish carefully between effort and
elapsed time
• 5.2. Revise plan to create controllable
activities
– break up very long activities into a series of
smaller ones
– bundle up very short activities (create check
lists?)

115
 Step 6: Identify activity risks
• 6.1.Identify and quantify risks for activities
– damage if risk occurs (measure in time lost or
money)
– likelihood if risk occurring
• 6.2. Plan risk reduction and contingency
measures
– risk reduction: activity to stop risk occurring
– contingency: action if risk does occur

116
 • 6.3 Adjust overall plans and estimates to
take account of risks
– e.g. add new activities which reduce risks
associated with other activities e.g. training,
pilot trials, information gathering

117
 Step 7: Allocate resources
• 7.1 Identify and allocate resources to activities
• 7.2 Revise plans and estimates to take into
account resource constraints
– e.g. staff not being available until a later date
– non-project activities

118
 LT = lead tester

Week commencing
Gantt charts TA = testing assistant
APRIL
MARCH
5 12 19 26 2 9 16

Survey potential
suppliers Finance assistant
Analyse existing
system Business analyst
Obtain user
requirements Business analyst

Generate test cases Systems assistant

Plan office layouts

Premises office

Calculate volumes
Systems assistant

Business
Draft and issue ITT
analyst
119
 Step 8: Review/publicise plan
• 8.1 Review quality aspects of project plan
• 8.2 Document plan and obtain agreement

Step 9 and 10: Execute plan and create

lower level plans

120
 Key points
• Establish your objectives
• Think about the characteristics of the project
• Discover/set up the infrastructure to support
the project (including standards)
• Identify products to be created and the
activities that will create them
• Allocate resources
• Set up quality processes

121