SOFTWARE PROJECT MANAGEMENT

SOFTWARE PROJECT
MANAGEMENT
OBJECTIVES

• To understand the Software Project Planning and Evaluation techniques.

• To plan and manage projects at each stage of the software development

life cycle (SDLC).

• To learn about the activity planning and risk management principles.
• To manage software projects and control software deliverables.
• To develop skills to manage the various phases involved in project

management and people management.

• To deliver successful software projects that support organization‘s

strategic goals.
UNIT I Introduction to Software Project Management:

Introduction to Project and Project Management, Reasons for IT project

failure, Triple constraint of IT project management, Management spectrum of
project, Overview of project life cycle models, Project manager skills and job
description conceptualization and initiation of IT project, Business case.

UNIT II Project Charter :

Introduction, Project management process and their correlation with project

life cycle phases, Introduction to Project Integration management and seven
processes, Project Charter.

Project Scope Management: Introduction, Processes of scope

management.
 UNIT III Project Human Resource Management:
Introduction, Organizational structure – Function, Project and
Matrix, Keys to managing people motivation theories and
improving effectiveness, Project team selection.
Project Time and Cost Management :
Introduction, Development of project schedule, CPM and
PERT, Activities their sequencing and dependencies, Project
network diagrams, Development of Gantt Charts, Earned
Value Management, Introduction to Constructive Cost Model
(COCOMO).
UNIT IV Project Risk Management : Introduction,
Risk Management Process, Risk Identification for IT
projects, Qualitative and Quantitative approaches to Risk
Analysis, Risk Strategies, Risk Monitoring and Control, Risk
Response and Evaluation Project Quality Management.

Project Communication Management:

Introduction, Project Communication Plan, Project

metrics, Information distribution, Performance Reporting.
Project Change Management: Introduction, Impact of
change, Change as a process, Change Management plan,
Dealing with resistance and conflict, Configuration
management.
 UNIT V Project Procurement Management:
Introduction, Processes Planning Purchases and
Acquisition, Contracting, Request Seller
Responses, Select Sellers, Contract
Administration, Contract Closure, Outsourcing of
products and services.

Project Leadership and Ethics:Introduction, Project

Leadership, Modern approaches, Styles of
leadership, Ethical leadership, Making sound
ethical decisions in the situations of conflict.
Closure of a Project: Introduction, Project
implementation, Administrative closure, Project
Evaluation.
OUTCOMES :

At the end of the course, the students should be able to:

• Understand Project Management principles while developing software.

• Gain extensive knowledge about the basic project management concepts,

framework and the process models.

• Obtain adequate knowledge about software process models and software effort
estimation techniques.

• Estimate the risks involved in various project activities.

• Define the checkpoints, project reporting structure, project progress and tracking
mechanisms using project management principles.

• Learn staff selection process and the issues related to people management
TEXT BOOK:

1. Bob Hughes, Mike Cotterell and Rajib Mall: Software Project Management
– Fifth Edition, Tata McGraw Hill, New Delhi, 2012.

REFERENCES:

1. Robert K. Wysocki ―Effective Software Project Management‖ – Wiley

Publication, 2011.

2. Walker Royce: ―Software Project Management‖- Addison-Wesley, 1998.

3. Gopalaswamy Ramesh, ―Managing Global Software Projects‖ – McGraw

Hill Education (India), Fourteenth Reprint 2013.
 UNIT I

UNIT I Introduction to Software Project Management:

Introduction to Project and Project Management,
Reasons for IT project failure, Triple constraint of IT project
management, Management spectrum of project, Overview of
project life cycle models, Project manager skills and job
description conceptualization and initiation of IT project,
Business case.
SOFTWARE CRISIS
 The term software crisis was used to describe
the impact of the rapid increase in computer
power and the complexity of the problems to
be tackled.
SOFTWARE CRISIS…
SOFTWARE CRISIS..
What is a project?

Some Dictionary Definitions are

 “ A Specific plan or design”
 “A planned Undertaking”
 “A Large Undertaking”

Key points above are planning and size of task…

Definition

A project is “a temporary endeavor undertaken to create a

unique product, service, or result”
 A project…
An endeavor with specific objectives:
 Usually consists of multiple tasks
 With defined precedence relationships
 With a specific time period for completion

Non-Software Examples?
A wedding
A BTech degree
A house construction project
A political election campaign
 JOBS VERSUS PROJECTS
 Tasks or Jobs – repetition of very well-defined and well
understood tasks with very little uncertainty
 Exploration – the outcome is very uncertain.. e.g. finding a cure
for cancer
 ‘Projects’ – in the middle! Has challenge as well as routine..
Therefore project management Important…
CHARACTERISTICS OF
PROJECTS
 Non-routine tasks are involved
 Planning is required
 Aiming at a specific target
 Work carried out for a customer
 Involving several specialisms
 Made up of several different phases
 Constrained by time and resources
 Large and/or complex
SOFTWARE PROJECT MANAGEMENT
DEFINITION
 Software project management is the art and
science of planning and leading software
projects.
 It is a sub-discipline of project management

in which software projects are planned,

implemented, monitored and controlled.
 It means to plan, organize and manage

resources to achieve goal and objective of the

project.
 It is a way to successfully apply your
knowledge, skills, tools, and techniques to
project activities in order to meet the
requirements of a project.
Are software projects really different from
other projects?

Not really! …but…

 Invisibility
 Complexity
 Conformity
 Flexibility
make software more problematic to build than other
engineered products.
TYPES OF SOFTWARE PROJECTS
 Two Types:
 Products(Generic software) or packaged s/w which
you can buy off the shelf (e.g Antivirus s/w, DBMS)
 Prewritten software available for purchase
 Services (custom software) which needs to be
developed (e.g McDonald's, Amazon, Uber, Netflix,
Google)
 s/w developed at user’s request
 Developer tailors its generic solution
Develop the Plan
The project manager will develop a project management plan. The project
includes many subsidiary plans, including cost management, schedule
management, project timeline, milestones, resource management, task
management, risk management, etc. These plans provide exact steps to
complete the project.
Execute the Plan
After developing and getting the project plan approved, you implement it to
complete the project. You will ensure the team understands the plan and their
roles and responsibilities. You will lead the project toward a successful
completion.
Control the Project
While executing the project, you will ensure the plan is progressing as planned,
there is no deviation from baselines, and the deliverable is developed per the
client’s expectation. If there is any deviation or defect in the project, you will take
necessary preventive and corrective actions.
Close the Project
Finally, you will deliver the final product to the client and close the project. Once
the project is completed, you will update the Lessons Learned document and
release the team.
 MANAGEMENT

Feasibility study
Is project technically feasible and worthwhile from a business
point of view?
Planning
Only done if project is feasible
Execution monitoring and control
Monitor and control plan implementation, but plan may be
changed as project proceeds
FEASIBILITY STUDY
 It assesses whether a project is worth
starting-that it has a valid business case.
 It is based on an outline design of system

requirements in terms of Input, Processes,

Output, Fields, Programs, and Procedures.
 This can be quantified in terms of volumes of

data, trends, frequency of updating, etc

PROJECT PLANNING

 Carried out before development starts.

 Important Activities:
 Estimation
 Scheduling
 Staffing
 Risk Management
 Miscellaneous Plans
MONITORING AND CONTROL

 Lasts for entire active project duration

 Monitoring – checking on progress, revising plans..

 Controlling – taking action to remedy hold-ups

 Innovating – coming up with solutions when problems

emerge…

 Representing – liaisoning with clients, users, developers and

other stakeholders…
 ISO 12207 LIFE-CYCLE
1. Requirements analysis
Requirements elicitation(or gathering): 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
2. Architecture design
🞑 Based on system requirements
🞑 Defines components of system: hardware, software, organizational
🞑 Software requirements will come out of this.
3.Detailed Design
Each component is made up of no. of software units that can be
tested separately
4. Code and test of individual components – writing code for each
software unit.
5. Integration
🞑 Putting the components together and tested together to see if they
meet the overall requirements.
ISO 12207

6. Qualification testing
🞑 Testing the system whether all the requirements have been fulfilled (not just
the software)
7. Installation
🞑 The process of making the new system operational.

🞑 Includes setting up standing data, setting system parameters,

installing on operational hardware platforms, user training etc.
8. Acceptance support
🞑 Including maintenance and enhancement
ACTIVITIES COVERED BY PROJECT MANAGEMENT

FIGURE-The lSO 12207 software development life cycle

 CATEGORIZATION OF SOFTWARE
PROJECTS
Distinguishing different types of project is important as different types of
task need different project approaches e.g.
Information systems versus embedded systems
Information systems
 Store data, process data and statistics
 Eg. MIS, Stock control software, patient management software, etc.
 Web based s/w vs Stand alone s/w

Embedded systems
 Controls h/w
 Eg. Automobile control software, robots, toys, TV remote..
STAKE HOLDERS
 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
 SETTING OBJECTIVES
 Answering the question ‘What do we have to do to have a project
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
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
GOALS/SUB-OBJECTIVES
These are steps along the way to achieving the objective. Informally, these can
be defined by completing the sentence…
Objective X will be achieved
IF the following goals are all achieved A……………
B…………… C…………… etc
Often a goal can be allocated to an individual.

Individual may have the capability of achieving goal, but not the objective on
their own e.g.

Objective – user satisfaction with software product

Analyst goal – accurate requirements

Developer goal – software that is reliable

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 means…

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
🞑 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
 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
 Modeling – 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
 BENEFITS
MANAGEMENT

developers users organization

us fo
e r
the
benefits
application
buil
d to
deliver
•Providing an organization with a capability does not guarantee that
this will provide benefits – need for benefits management
•This has to be outside the project – project will have been
completed.. Therefore done at programme level.. 38
 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

39
Cost benefit analysis (CBA)
You need to:
 Identify all the costs which could be:
🞑 Development costs, Set-up, Operational costs
 Identify the value of benefits
 Check benefits are greater than costs
COST BENEFIT ANALYSIS (CBA)/ COST
BENEFIT EVALUATION
TECHNIQUES(CBET)
Net profit
Year Cash-flow
‘Year 0’ represents all the
0 -100,000 costs before system is operation
1 10,000 ‘Cash-flow’ is value of
2 10,000 incomeless
3 10,000 outgoing
4 20,000 Net profit value of all the cash-flows for
the lifetime of the application
5 100,000
Net
50,000
profit
COST BENEFIT ANALYSIS (CBA)/ COST
BENEFIT EVALUATION
TECHNIQUES(CBET)
Pay back period This is the time it takes to
start generating a surplus of income over
outgoings. What would it be below?
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
COST BENEFIT ANALYSIS (CBA)/ COST
BENEFIT EVALUATION
TECHNIQUES(CBET)
Return on investment
(ROI)ROI Average annual X
profit Total
= 100
investment
In the previous example
•average annual profit
= 50,000/5
= 10,000
•ROI = 10,000/100,000 X
100
= 10%
COST BENEFIT ANALYSIS (CBA)/ COST
BENEFIT EVALUATION
TECHNIQUES(CBET)

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
COST BENEFIT ANALYSIS (CBA)/ COST
BENEFIT EVALUATION
TECHNIQUES(CBET)
Discount factor Applying discount factors
Discount factor = 1/(1+r)t r is the
Year Cash- Discount Discount
interest rate (e.g. 10% is 0.10) flow factor ed cash
t is the number of years flow
In the case of 10% rate and one 0 -100,000 1.0000 -100,000
year Discount factor = 1/(1+0.10)
1 10,000 0.9091 9,091
= 0.9091
2 10,000 0.8264 8,264
In the case of 10% rate and two
years 3 10,000 0.7513 7,513
Discount factor = 1/(1.10 x 1.10) 4 20,000 0.6830 13,660
=0.8294 5 100,000 0.6209 62,090
NPV 618
COST BENEFIT ANALYSIS (CBA)/ COST
BENEFIT EVALUATION
TECHNIQUES(CBET)

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
 RISK EVALUATION

Dealing with uncertainty:

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
Example of a project risk matrix
Risk evaluation

Decision trees
 PROGRAMME
MANAGEMENT

 Definition:
Strategic
‘a group of projects
 Business thatprogrammes
cycle are managed in a co-ordinated way to gain
benefits that would not be possible were the projects to be managed
 Infrastructure programmes
independently’ Ferns
 Research and development programmes
Programmes may be
Innovative partnerships
PROGRAMME MANAGERS VERSUS PROJECT
MANAGERS

Programme manager Project manager

🞑 Many simultaneous 🞑 One project at a time
projects 🞑 Impersonal relationship
🞑 Personal relationship with resources
with skilled resources 🞑 Minimization of
🞑 Optimization of demand for resources
resource use 🞑 Projects tend to be seen
🞑 Projects tend to be seen as unique
as similar
50
 STRATEGIC PROGRAMMES
 Based on OGC 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

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
STEP WISE PROJECT
PLANNING

 Practicality
🞑tries to answer the question ‘what do I do now?’
 Scalability

🞑useful for small project as well as large

 Range of application

 Accepted techniques

🞑e.g. borrowed from PRINCE etc

‘STEP WISE’ - AN
OVERVIEW

0.Select
1. Identify project 2. Identify
project project
objectives infrastructur
3. e
Analyse
project
Revie character
4. Identify
istics
w products
and activities
5.
5. Estimate
Estimate
Lowe effort
effort for For
r foractivity
activity
6.
6. Identify
Identify each
level activit
activity
activity
detail y
10.
10. Lower
Lower level risks risks
level 7. Allocate
planning
planning resources

8. Review/
9. Execute plan publicize
plan
 A PROJECT SCENARIO
 Hardware/software engineering company (C++
language of choice)
 teams are selected for individual projects - some friction
has been found between team members
 HR manager suggests psychometric testing to select team
 Software package to be used to test staff
 Visual basic suggested as a vehicle for implementation
 usability is important - decision to carry out usability tests
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?’
 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?’

 BACK TO THE SCENARIO
 Project authority
🞑 should be a project manager rather than HR manager?
 Stakeholders

🞑 project team members to complete on-line questionnaires:

concern about results?
 Revision to objectives

🞑 provide feedback to team members on results

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?’

 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?
 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?’
 BACK TO THE SCENARIO

 Objectives vs. products

🞑 use paper questionnaire then input results of the analysis?
 Some risks

🞑 team members worried about implications

and do no co-
operate
🞑 project managers unwilling to try out application

🞑 Developer not familiar with features of VB

 Answer? - evolutionary prototype?
STEP 4 IDENTIFY PROJECT PRODUCTS AND
ACTIVITIES

4.1 Identify and describe project products - ‘what do we

have to produce?’

Usability A product breakdown structure

testing (PBS)

Selected Testing Change

Test results
subjects arrangements requests

Booked PC Questionnaire Completed Analysis

design questionnaire report
 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’)
 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
PRODUCT DESCRIPTION (PD)

 Product identity
 Description - what is it?
 Derivation - what is it based on?
 Composition - what does it contain?
 Format
 Relevant standards
 Quality criteria

Create a PD for ‘test data’

STEP 4
CONTINUED

4.2 document Generic Product

flows
Testing Step 4.3 Recognize product
plan instances
 The PBS and PFD will probably
Select Questionn Booke have identified generic products
ed aire d
design
e.g. ‘software modules’
subjec machi
ts ne  It might be possible to identify
Completed Test specific instances e.g. ‘module A’,
results ‘module B’ …
questionnai
re  But in many cases this will have to
be left to later, more detailed,
Analysis planning
report
Change
requests
 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
Select
subjects

Plan Design Conduct Analyse Draft change

testing questionnaire tests results requests

Book
machine
STEP 4.5 ADD CHECK-
POINTS IF NEEDED

Design Code
module A module A

Design Design Code Test

system module module B system
B

Design Code put in

module C module C a check
point
Design Code
module A module A

Design Design Code

Check-point Test
system module B module B system

Design Code
module C module C
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?)

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
 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

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
 LT = lead tester
GANTT CHARTS
Wee APRI
TA = testing
MARC assistant
kcommencing H L
5 1 1 2 2 9 1
2 9 6 6
Plan L
testing T
Select
subjects T
Design A
questionn L
aire T
Book T
machine A
Conduct
tests T
Analyse A
results L
T
Draft
changes L
T
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