1. Software Pr j t
S ft r Project
Manage ent
Management
R. Akerkar
TMRF, K lh
TMRF Kolhapur, India
I di
R. Akerkar - SPM 1

2. Introduction
 Many software projects fail:
 due to faulty project
management practices:
 It is important to learn different
aspects of software project
management.
management
R. Akerkar - SPM 2

3. Introduction
 Goal
of software project
management:
g
 enable a group of engineers to work
efficiently towards successful
completion of a software project.
R. Akerkar - SPM 3

4. Responsibility of project managers
 Project proposal writing
writing,
 Project cost estimation,
 Scheduling,
g,
 Project staffing,
 Project monitoring and control,
 Software configuration management,
 Risk management,
 Managerial report writing and presentations, etc.
M i l t iti d t ti t
R. Akerkar - SPM 4

5. Introduction
A project manager’s activities
manager s
are varied.
 can be broadly classified into:
 project planning
planning,
 project monitoring and control
activities.
R. Akerkar - SPM 5

6. Project Planning
j g
 Once a project is found to be
feasible,
 project managers undertake project
p
planning.
g
R. Akerkar - SPM 6

7. Project Planning Activities
j g
 Estimation:
 Effort, cost, resource, and project duration
 Project scheduling:
j g
 Staff organization:
 staffing plans
 Risk handling:
Ri k h dli
 identification, analysis, and abatement procedures
 Miscellaneous plans:
 quality assurance plan, configuration management
plan, etc.
R. Akerkar - SPM 7

8. Project p
j planning
g
 Requires utmost care and attention ---
commitments to unrealistic time and resource
estimates result in:
 irritating delays.
 cus o e dissatisfaction
customer d ssa s ac o
 adverse affect on team morale
 poor quality work
 project failure.
R. Akerkar - SPM 8

9. Sliding Window Planning
g g
 Involves project planning over
several stages:
 protects managers from making big
commitments too early. y
 More information becomes available
as project progresses
progresses.
 Facilitates accurate planning
R. Akerkar - SPM 9

10. SPMP Document
 After planning is complete:
 Document the plans:
p
 in a Software Project
Management Plan(SPMP)
document.
R. Akerkar - SPM 10

11. Organization of SPMP Document
g
 Introduction (Objectives Major Functions,Performance Issues,Management and
(Objectives,Major Functions Performance Issues Management
Technical Constraints)
 Project Estimates (Historical Data,Estimation Techniques,Effort, Cost, and Project
Duration Estimates)
)
 Project Resources Plan (People,Hardware and Software,Special
Resources)
 Schedules (Work Breakdown Structure,Task Network, Gantt Chart Representation,PERT
Chart Representation)
 Risk Management Plan (Risk Analysis,Risk Identification,Risk Estimation,
Abatement Procedures)
 Project Tracking and Control Plan
 Miscellaneous Plans(Process Tailoring Quality Assurance)
Tailoring,Quality
R. Akerkar - SPM 11

12. Software Cost Estimation
 Determine size of the product
product.
 From the size estimate,
 determine the effort needed
needed.
 From the effort estimate,
 determine project duration, and cost.
R. Akerkar - SPM 12

13. Software Cost Estimation
Effort Cost
Estimation Estimation
Size Staffing
Estimation Estimation
Duration
Estimation Scheduling
R. Akerkar - SPM 13

14. Organization Structure
g
 Functional Organization:
 Engineers are organized into functional
groups, e.g.
groups e g
 specification, design, coding, testing,
maintenance, etc.
maintenance etc
 Engineers from functional groups get
assigned to different projects
R. Akerkar - SPM 14

15. Advantages of Functional
Organization
 Specialization
 Ease of staffing
 Good documentation is produced
 d e e t phases are carried
different p ases a e ca ed out by d e e t
different
teams of engineers.
 Helps identify errors earlier
earlier.
R. Akerkar - SPM 15

16. Project Organization
j g
 Engineers get assigned to a project for
the entire duration of the project
 Same set of engineers carry out all the
phases
 Advantages:
 Engineers save time on learning details of
every project
project.
 Leads to job rotation
R. Akerkar - SPM 16

17. Team Structure
 Problems of different complexities
and sizes require different team
structures:
 Chief programmer
Chief-programmer team
 Democratic team
 Mi
Mixed organization
d i ti
R. Akerkar - SPM 17

18. Democratic Teams
 Suitable for:
 small projects requiring less than five or six
engineers
i
 research-oriented projects
 A manager provides administrative
p
leadership:
 at different times different members of the
g p provide technical leadership.
group p p
R. Akerkar - SPM 18

19. Democratic Teams
 Democratic organization provides
 higher morale and job satisfaction to the engineers
 therefore leads to less employee turnover
turnover.
 Suitable for less understood problems,
 a group of engineers can invent better solutions
than a single individual.
R. Akerkar - SPM 19

20. Democratic Teams
 Di
Disadvantage:
d t
 team members may waste a lot
time arguing about trivial points:
 absence of any authority i th
b f th it in the
team.
R. Akerkar - SPM 20

21. Chief Programmer Team
g
A senior engineer provides
technical leadership:
 partitions the task among the team
members.
 verifies and integrates the products
developed by the members.
R. Akerkar - SPM 21

22. Chief Programmer Team
g
 Works well when
 the task is well understood
 also within the intellectual grasp of a single
individual,
 importance of early completion outweighs
other factors
 team morale, personal development, etc.
R. Akerkar - SPM 22

23. Chief Programmer Team
g
 Chief programmer team is subject to
single point failure:
 too
t much responsibility and authority is
h ibilit d th it i
assigned to the chief programmer.
R. Akerkar - SPM 23

24. Team Organization
g
Democratic Team
Chief Programmer team
R. Akerkar - SPM 24

25. Mixed team organization
g
R. Akerkar - SPM 25

26. Staffing
 Project Managers usually
take responsibility for
choosing their team:
h i th i t
 need to identify and select
y
good software engineers for
the success of the project
project.
R. Akerkar - SPM 26

27. Staffing
 A common misconception:
p
 one software engineer is as productive as
another:
 Experiments reveal:
E i t l
 a large variation in productivity between
the worst and best in a scale of 1 to 10.
10
 Worst engineers even help reduce the
overall productivity of the team
 in effect exhibit negative productivity.
R. Akerkar - SPM 27

28. Who is a Good Software Engineer?
 Good programming abilities
 Good knowledge of the project areas (Domain)
G dk l d f h j (D i )
 Exposure to Systematic Techniques
 Fundamental Knowledge of Computer Science
 Ability to work in a team
 Intelligence
 Good communication skills:
 Oral
 Written
 Interpersonal
 High Motivation
R. Akerkar - SPM 28

29. Who is a Good Software Engineer? (cont.)
 Studies show:
 these attributes vary as much as
1:30 for poor and bright candidates.
 Technical knowledge in the area of the
project (domain knowledge) is an
important factor, determines:
 productivity of an individual
 quality of the product he develops.
R. Akerkar - SPM 29

30. Who is a Good Software Engineer? (cont.)
 A programmer having thorough
knowledge of database
applications (e.g MIS):
(e g
 may turn out to be a poor data
communication engineer
engineer.
R. Akerkar - SPM 30

31. Scheduling
 Scheduling is an important activity for the
g y
project managers.
 To determine project schedule:
 Identify tasks needed to complete the project.
 Determine the dependency among different tasks.
 Determine the most likely estimates for the duration
of the identified tasks.
 Plan the starting and ending dates for various
tasks.
t k
R. Akerkar - SPM 31

32. Work Breakdown Structure
 Work Breakdown Structure (WBS) provides a notation
for
f representing task structure:
i k
 Activities are represented as nodes of a tree.
 The root of the tree is labelled by the problem name.
 Each task is broken down into smaller tasks and
represented as children nodes.
 It is not useful to subdivide tasks into units which take
less than a week or two to execute.
 Finer subdivisions mean that a large amount of time
must be spent on estimating and chart revision.
R. Akerkar - SPM 32

33. Work Breakdown Structure
Compiler Project
p j
Requirements Design Code Test Write Manual
Lexer Parser Code Generator
R. Akerkar - SPM 33

34. Activity Networks
 WBS structure can be refined into an
activity network representation:
 Network of boxes and arrows
 shows different tasks making up a project,
h diff tt k ki j t
 represents the ordering among the tasks.
 It is important to realize that developing
WBS and activity network
 requires a thorough understanding of the
tasks involved.
R. Akerkar - SPM 34

35. Activity Network
Code Lexer
Design Code Parser
Requirements Code Code Generator Test
Write Manual
R. Akerkar - SPM 35

36. Risk Management
 A risk is any unfavourable event or
circumstance:
 which might hamper successful or timely
completion of a project.
p p j
 Risk management:
 concerned with the reduction of the impact of risks.
 Risk management consists of three activities:
 risk identification,
 risk assessment, and
 risk containment.
i k t i t
R. Akerkar - SPM 36

37. Risk identification
 To be able to identify various risks:
y
 we must categorize risks into different
classes.
 Three main categories of risks can
affect a software project:
 project risks
 technical risks
 business risks
R. Akerkar - SPM 37

38. Project Risks
j
 Project risks associated with:
 budget,
 schedule,
 personnel,
p ,
 resource, and
 customer problems.
t bl
R. Akerkar - SPM 38

39. Technical Risks
 Technical risks concern:
 requirements specification
 (e.g ambiguous, incomplete, changing specifications)
 design problems,
problems
 implementation problems,
 interfacing problems,
gp ,
 testing, and maintenance problems.
 technical uncertainty, and technical obsolescence
are technical risk factors too
too.
R. Akerkar - SPM 39

40. Business Risks
 Business Risks include:
 building an excellent product that no one wants,
 losing budgetary or personnel commitments, etc.
 It i
I is a good idea to have a “
d id h “company di
disaster
list”,
 a list of all bad things that have happened in the
past
 project managers can jog their mind to see which
items th i project is vulnerable to.
it their j ti l bl t
R. Akerkar - SPM 40

41. Risk assessment
 Objective of risk assessment is to
j
prioritize the risks:
 Likelihood of a risk being real.
 C
Consequence of th problems associated
f the bl i t d
with that risk.
 Prioritization helps in handling the most
damaging risks first.
 Priority of a risk is the product of the likelihood of
the risk and the consequences of the problems
associated with that risk.
R. Akerkar - SPM 41

42. Risk Handling
g
 Three main strategies for risk handling:
 Avoid the risk: e.g. change the requirements for
performance or functionality.
 Transfer the risk: allocate risks to third party
 or buy insurance to cover any financial loss should
the risk become a reality.
 Contingency planning: Prepare contingency pans
to minimize the impact of the risk.
R. Akerkar - SPM 42