Software Project Management

Course Objectives

 Understand the fundamental principles of Software Project

management & will also have a good knowledge of responsibilities
of project manager and how to handle these.

 Be familiar with the different methods and techniques used for

project management.

 By the end of this course student will have good knowledge of the
issues and challenges faced while doing the Software project
Management and will also be able to understand why majority of the
software projects fails and how that failure probability can be
reduced effectively. Will be able to do the Project Scheduling,
tracking, Risk analysis, Quality management and Project Cost
estimation using different techniques
 Project – Definition

 In the broadest sense, a project is a specific,

finite task to be accomplished. Any activity that
results in a deliverable or a product.

 Projects always begin with a problem. The

project is to provide the solution to this
problem.

 When the project is finished it must be

evaluated to determine whether it satisfies the
objectives and goals.
What is Management?

 Management can be defined as all activities and tasks

undertaken by one or more persons for the purpose of
planning and controlling the activities of others in order
to achieve objectives or complete an activity that could
not be achieved by others acting independently.
 Management functions can be categorized as
 Planning
 Organizing
 Staffing
 Directing
 Controlling
Management Functions
 Planning
Predetermining a course of action for accomplishing
organizational Objectives
 Organizing
Arranging the relationships among work units for
accomplishment of objectives and the granting of
responsibility and authority to obtain those objectives
 Staffing
Selecting and training people for positions in the
organization
 Directing
Creating an atmosphere that will assist and motivate
people to achieve desired end results
 Controlling
Establishing, measuring, and evaluating performance of
activities toward planned objectives
What is Project Management
 “The application of knowledge, skills,
tools and techniques to project
activities in order to meet project
requirements”
What is Project Management
Project management is a system of
 management procedures,
 practices,
 technologies,
 skills, and
 experience
that are necessary to successfully
manage a project.
Software Project Management
Concerned with activities involved in
ensuring
that software is delivered:
 on time
 on schedule
 in accordance with the requirements
of the organization developing and
procuring the software
Project Stakeholders
Stakeholders are the people involved
in or affected by the project actives
 Stakeholders include
 The project sponsor and project team
 Support staff
 Customers
 Users
 Suppliers
 Opponents to the project
Project Characteristics

 One clear objective

 A well defined set of end results
 Goal oriented
 End product or service must result

 Finite
 Fixed timeline, start date, end date, milestone dates

 Limited
 Budget, Resources, Time

 Life Cycle
 Recognizable sequence of phases
 Product

Project People

Software Project Management

Product Project People

1. Assessing Processes 12. Building a WBS 23. Appraising Performance

2. Awareness of Process Standards 13. Documenting Plans 24. Handling Intellectual Property
3. Defining the Product 14. Estimating Costs  25. Holding Effective Meetings
4. Evaluating Alternative Processes 15. Estimating Effort 26. Interaction and Communication
5. Managing Requirements 16. Managing Risks 27. Leadership
6. Managing Subcontractors 17. Monitoring Development 28. Managing Change
7. Performing the Initial Assessment 18. Scheduling 29. Negotiating Successfully
8. Selecting Methods and Tools 19. Selecting Metrics 30. Planning Careers
9. Tailoring Processes 20. Selecting Project  Management 31. Presenting Effectively
10. Tracking Product Quality Tools 32. Recruiting
11. Understanding Development Activities 21. Tracking Process 33. Selecting a Team
22. Tracking Project Progress 34. Teambuilding

34 Competencies Every Software Project Manager Needs to Know

Product Life Cycles
Products also have life cycles
The Systems Development Life Cycle
(SDLC) is a framework for describing
the phases involved in developing and
maintaining information systems
Typical SDLC phases include planning,
analysis, design, implementation, and
support
Steps in SDLC
 Concept Exploration
 System exploration
 Requirements
 Design
 Implementation
 Installation
 Operations and support
 Maintenance
 Retirement
Process & Process Model
Software Process
 the set of activities, methods, and
practices that are used in the production
and evolution of software
Software Process Model
 one specific embodiment of a software
process architecture
Project planning
Software project management
• Informal definition of management
– The art of getting work done through other people
• Software project management is 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
Management activities
 Proposal writing
 Project planning and scheduling
 Project costing
 Project monitoring and reviews
 Personnel selection and evaluation
 Report writing and presentations
Who needs software?

Most software is built in organizations for people

with specific needs.
◦ A stakeholder is a anyone who has an interest (or stake) in the
software being completed
◦ A user is someone who will need to use the software to perform
tasks.
◦ Sometimes stakeholders will be users; but often the stakeholder
will not use the software.
 For example, a senior manager (like a CEO - chief executive officer
or CTO - Chief technology officer in a company) will usually have a
stake in the software that is built (since it affects the bottom line),
even if she won’t ever use it.
STAKEHOLDER:

-SPONSOR
- CUSTOMER
- FUNCTIONAL/MANAGERS
- PROJECT MANAGER
- PROJECT TEAM MEMBER
Classifying stakeholders
 Example: Classifying stakeholders – an airline
booking system
An international airline is considering introducing a new booking
system for use by associated travel agents to sell flights directly to
the public.
 Primary stakeholders: travel agency staff, airline booking
staff
 Secondary stakeholders: customers, airline management
 Tertiary stakeholders: competitors, civil aviation
authorities, customers’ travelling companions, airline shareholders
 Facilitating stakeholders: design team, IT department staff
Who builds software?
Software is typically built by a team of software engineers,
which includes:
◦ Business analysts or requirements analysts who talk to users and
stakeholders, plan the behavior of software and write software
requirements
◦ Designers and architects who plan the technical solution
◦ Programmers who write the code
◦ Testers who verify that the software meets its requirements and
behaves as expected
Project Management
The project manager plans and guides the software
project
◦ The project manager is responsible for identifying the users and
stakeholders and determining their needs
◦ The project manager coordinates the team, ensuring that each task
has an appropriate software engineer assigned and that each engineer
has sufficient knowledge to perform it
◦ To do this well, the project manager must be familiar with every
aspect of software engineering
Identifying Needs
 The project manager drives the scope
of the project.
 Why?
 The project manager should identify and talk to the
main stakeholder
 The effective way to show stakeholders that their needs
are understood and that those specific needs will be
addressed is with a vision and scope document
 Vision and Scope Document
 A typical vision and scope document follows an outline like this
one:
1. Problem Statement
a)Project background
b)Stakeholders
c) Users
d)Risks
e) Assumptions
2. Vision of the Solution
a)Vision statement
b)List of features
c) Scope of phased release (optional)
d)Features that will not be developed
Vision and Scope Document
 Project background
 a summary of the problem that the project will solve.
 It should provide a brief history of the problem and an
explanation of how the organization justified the decision
to build software to address it.
 cover the reasons why the problem exists, the
organization's history with this problem, any previous
projects that were undertaken to try to address it, and
the way that the decision to begin this project was
reached.
Vision and Scope Document
 Stakeholders
 This is a bulleted list of the stakeholders.
 Each stakeholder may be referred to by name, title, or
role ("support group manager," "CTO," "senior
manager").
 The needs of each stakeholder are described in a few
sentences.
Vision and Scope Document
Users
◦ This is a bulleted list of the users. As with the
stakeholders, each user can either be referred to by
name or role ("support rep," "call quality auditor,"
"home web site user")
◦ however, if there are many users, it is usually
inefficient to try to name each one. The needs of
each user are described.
Vision and Scope Document
Risks

lists any potential risks to the project.

It should be generated by a project team's brainstorming

session.

It could include external factors that may impact the project, or

issues or problems that could potentially cause project delays

or raise issues. (The process for assessing and mitigating risk
below can be used to generate the risks for this section.)
Vision and Scope Document
Assumptions
◦ the list of assumptions that the stakeholders, users, or project team
have made.
◦ Often, these assumptions are generated during a Wideband Delphi
estimation session (Lesson 3).
 If Wideband Delphi is being used, the rest of the vision and scope
document should be ready before the Delphi meeting and used as the basis
for estimation.

◦ If Wideband Delphi is not being used to generate the assumptions,

the project manager should hold a brainstorming session with the
team to come up with a list of assumptions instead (Lesson 3).
Vision and Scope Document
Vision statement
◦ The goal of the vision statement is to describe what the
project is expected to accomplish. It should explain what the
purpose of the project is.
◦ This should be a compelling reason, a solid justification for
spending time, money, and resources on the project. The
best time to write the vision statement is after talking to the
stakeholders and users and writing down their needs; by this
time, a concrete understanding of the project should be
starting to jell.
 List of features
 A feature is as a cohesive area of the software that fulfills a specific need by providing a
set of services or capabilities.
 Any software package in fact, any engineered product can be broken down into features.
 The project manager can choose the number of features in the vision and scope
document by changing the level of detail or granularity of each feature, and by
combining multiple features into a single one.
 It is useful to describe a product in about 10 features in the vision and scope document ,
because this usually yields a level of complexity that most people reading it are
comfortable with.
 Each feature should be listed in a separate paragraph or bullet point. It should be given a
name, followed by a description of the functionality that it provides. This description does
not need to be detailed; it can simply be a few sentences that give a general explanation
of the feature. However, if there is more information that a stakeholder or project team
member feels should be included, it is important to include that information.
 Features that will not be developed
 Features are often left out of a project on purpose. It
should be added to this section to tell the reader that
a decision was made to exclude it.
 For example, one way to handle an unrealistic deadline
is by removing one or more features from the
software, in which case the removed features should
be moved into this section.
Review the vision and scope document
Once the vision and scope document has been written, it should
be reviewed by every stakeholder, by the members of the
project team, and, ideally, by at least a few people who will
actually be using the software.
Performing this review
◦ can be as simple as emailing the document around and asking for
comments.
◦ The document can also be inspected.
◦ it is important that the project manager follow up with each individual
person and work to understand any issues that the reviewer brings up.
◦ The project manager should make sure that everyone agrees that the
final document really reflects the needs of the stakeholders and the
users.
◦ Once the document has been reviewed and everyone agrees that it is
complete, the team is unified toward a single goal and the project can
be planned.
 Project Plan
The project plan defines the work that will be done on
the project and who will do it. It consists of:
◦ A statement of work (SOW) that describes all work products that
will be produced and a list of people who will perform that work
◦ A resource list that contains a list of all resources that will be
needed for the product and their availability
◦ A work breakdown structure and a set of estimates
◦ A project schedule
◦ A risk plan that identifies any risks that might be encountered
and indicates how those risks would be handled should they
occur
Statement of Work
 The statement of work (SOW) is a
detailed description of all of the work
products which will be created over
the course of the project. It includes:
 A list of features that will be developed
 A description of each intermediate
deliverable or work product that will be
built.
 The estimated effort involved for each
work product to be delivered
Resource List
 The project plan should contain a list
of all resources that will be used on
the project.
 A resource is a person, hardware, room
or anything else that is necessary for the
project but limited in its availability
 The resource list should give each
resource a name, a brief one-line
description, and list the availability and
cost (if applicable) of the resource
Estimates and Project Schedule
 The project plan should also include estimates
and a project schedule:
 A work breakdown structure (WBS) is defined. This is
a list of tasks which, if performed, will generate all of
the work products needed to build the software.
 An estimate of the effort required for each task in the
WBS is generated.
 A project schedule is created by assigning resources
and determining the calendar time required for each
task.
Project planning
 A plan, drawn up at the start of the
project, should be used as the driver
for the project
 The initial plan should be the best
possible plan given the available
information. It must be regularly
revised as new information becomes
available
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
The project plan
 The project plan sets out:
 The resources available to the project
 The work breakdown
 A schedule for the work
Project plan structure
 Introduction
 Objectives, constraints (e.g., budget, time, etc…)
 Project organisation
 People involved and their roles in the team
 Risk analysis
 Possible risks, their likelihood and reduction strategies
 Hardware and software resource requirements
 Work breakdown
 Breaks down the project into activities, identifies
milestones, deliverables
 Project schedule
 Activity dependencies, estimated milestone time, people
allocation
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
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
 Important to note that the schedule evolves over time.
During early stages of planning, a macroscopic
schedule is developed that identifies all major SE
activities. As the project gets under way, each entry is
refined into a detailed schedule where specific tasks
required to accomplish an activity are identified and
scheduled
Scheduling problems
 Estimating the difficulty of problems and hence
the cost of developing a solution is hard
 Common myth: “If we fall behind schedule, we
can always add more programmers and catch up
later in the project”
 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 (CLASS DISCUSSION)
 Example: 4 software engineers, each capable of
producing 5000 LOC/year, are working on an individual
project. They are placed on a team project. Assume
the overhead associated with each communication
path is 250 LOC/year. What will the team productivity
be?
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 critical path
• Activity Bar charts show schedule
against calendar time
 Task durations and
dependencies

What is the minimum total duration of this project?

 Activity network

What if T8 is delayed by 14 days?

Activity bar chart (Gantt chart)
“slack” tim

one week, 5
business/worki
ng days
Staff allocation