Software Project Management

Lecture Notes

UNIT-I
Introduction and Software Project Planning
For
Third Year Students MCA

Page 1 of 22

Fundamentals of Software Project Management:

Elements of Management
1.
2.
3.
4.
5.
6.
7.
8.

Planning deciding what to do

Organizing making arrangements
Staffing selecting the right people for the job etc.
Directing giving instructions
Monitoring checking on progress
Controlling taking action to remedy hold-ups
Innovating coming up with new solutions
Representing liaising with clients, users, developer, suppliers and other stakeholders.

What is Software: Software is a general term for the various kinds of programs used to
operate computers and related devices.
OR
Software means computer instructions or data. Anything that can be stored electronically is
software, in contrast to storage devices and display devices which are called hardware.

What is a Project: planned activity

A unique process, consisting of a set of coordinated and controlled activities with start and finish dates,
undertaken to achieve an objective conforming to specific requirements including constraints of time,
cost and resources
Some dictionary definitions:

A specific plan or design

A planned undertaking
A large undertaking e.g. a public works scheme
Page 2 of 22

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!

Software projects vs. other type of 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 artefacts.

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
Page 3 of 22

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

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
Qualification testing
Testing the system (not just the software)
Installation
Page 4 of 22

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

Some ways of categorizing projects

Distinguishing different types of project is important as different types of task need different
project approaches e.g.
Information systems versus embedded systems
Objective-based versus product-based
A traditional distinction has been between information system which enable staff to carry out
office process and embedded system which control machines.
Stock control system -> information system
Air condition equipment in a building -> embedded system
Some system may have both the systems.
For example: stock control system also controls an automated warehouse.

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

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

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

Page 5 of 22

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

Project 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

Page 6 of 22

The business case

Organization may have different titles such as a feasibility study or a project justification for
what we call business case.
Its objective is to provide a rationale for the project by showing that the benefits of the project
outcomes will exceed the costs of development.
A business case document might contain:
1. Introduction and background to the proposal.
2. The proposed project
3. The market
4. Organization and operation infrastructure
5. The benefits
6. Outline implementation plan
7. Costs
8. The financial case
9. Management plan

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

Page 7 of 22

The Management Spectrum : The management spectrum describes the management of a

software project or how to make a project successful. It focuses on the four Ps; people, product,
process and project. Here, the manager of the project has to control all these Ps to have a smooth
flow in the project progress and to reach the goal.
The four Ps of management spectrum has been described briefly in below.

The People: People of a project includes from manager to developer, from customer to end user.
But mainly people of a project highlight the developers. It is so important to have highly skilled
and motivated developers that the Software Engineering Institute has developed a People
Management Capability Maturity Model (PM-CMM), to enhance the readiness of software
organizations to undertake increasingly complex applications by helping to attract, grow,
motivate, deploy, and retain the talent needed to improve their software development
capability. Organizations that achieve high levels of maturity in the people management area
have a higher likelihood of implementing effective software engineering practices.

The Product: Product is any software that has to be developed. To develop successfully, product
objectives and scope should be established, alternative solutions should be considered, and
technical and management constraints should be identified. Without this information, it is
impossible to define reasonable and accurate estimates of the cost, an effective assessment of risk,
a realistic breakdown of project tasks or a manageable project schedule that provides a
meaningful indication of progress.

The Process: A software process provides the framework from which a comprehensive plan for
software development can be established. A number of different tasks sets tasks, milestones,
work products, and quality assurance pointsenable the framework activities to be adapted to
the characteristics of the software project and the requirements of the project team. Finally,
umbrella activities overlay the process model. Umbrella activities are independent of any one
framework activity and occur throughout the process.

The Project: Here, the manager has to do some job. The project includes all and everything of
the total development process and to avoid project failure the manager has to take some steps,
has to be concerned about some common warnings etc.

Law of project Management:

Projects progress quickly until they are 90% complete. Then they remain at 90%
complete forever.
When things are going well, something will go wrong. When things just cant get worse,
they will. When things appear to be going better, you have overlooked something.
If project content is allowed to change freely, the rate of change will exceed the rate of
progress.
Project teams detest progress reporting because it manifests their lack of progress.

Page 8 of 22

How it should go
Requirements
Analysis
Design

Implementation

System Testing

Delivery and Installation

How it often goes

Requirements
Analysis

D
E
L
A
Y

Vaporware

Page 9 of 22

Software Project Management Plan

Software Project:
All technical and managerial activities required to deliver the deliverables to the
client.
A software project has a specific duration, consumes resources and produces work
products.
Management categories to complete a software project:
Tasks, Activities, Functions
Software Project Management Plan:
The controlling document for a software project.
Specifies the technical and managerial approaches to develop the software
product.
Companion document to requirements analysis document: Changes in either may
imply changes in the other document.
SPMP may be part of project agreement.

Project Agreement
Document written for a client that defines:
the scope, duration, cost and deliverables for the project.
the exact items, quantities, delivery dates, delivery location.
Can be a contract, a statement of work, a business plan, or a project charter.
Client: Individual or organization that specifies the requirements and accepts the project
deliverables.
Deliverables (= Work Products that will be delivered to the client):
Documents
Demonstrations of function
Demonstration of nonfunctional requirements
Demonstrations of subsystems

Page 10 of 22

Project Management Life Cycle

Project Management Life Cycle comprises four phases...

Initiation involves starting up the project, by

documenting a business case, feasibility study,
terms of reference, appointing the team and
setting up a Project Office.

Planning involves setting out the roadmap for

the project by creating the following plans:
project plan, resource plan, financial plan,
quality plan, acceptance plan and
communications plan.
Execution involves building the deliverables
and controlling the project delivery, scope,
costs, quality, risks and issues.

Closure involves winding-down the project by

releasing staff, handing over deliverables to the
customer and completing a post
implementation review.

A more detailed description of the Project Management Methodology and Life Cycle follows:

Project Initiation
Project Initiation is the first phase in the Project Life Cycle and essentially involves starting up
the project. You initiate a project by defining its purpose and scope, the justification for initiating
it and the solution to be implemented. You will also need to recruit a suitably skilled project
team, set up a Project Office and perform an end of Phase Review. The Project Initiation phase
involves the following six key steps:

Project Planning
After defining the project and appointing the project team, you're ready to enter the detailed
Project Planning phase. This involves creating a suite of planning documents to help guide the
team throughout the project delivery. The Planning Phase involves completing the following 10
key steps:
Page 11 of 22

Project Execution
With a clear definition of the project and a suite of
detailed project plans, you are now ready to enter the
Execution phase of the project.
This is the phase in which the deliverables are
physically built and presented to the customer for
acceptance.
While each deliverable is being constructed, a suite of
management processes are undertaken to monitor and
control the deliverables being output by the project.
These processes include managing time, cost, quality,
change, risks, issues, suppliers, customers and
communication.
Once all the deliverables have been produced and the
customer has accepted the final solution, the project is
ready for closure.

Project Closure
Project Closure involves releasing the final deliverables to the
customer, handing over project documentation to the
business, terminating supplier contracts, releasing project
resources and communicating project closure to all
stakeholders. The last remaining step is to undertake a Post Implementation Review to identify
the level of project success and note any lessons learned for future projects.

Page 12 of 22

Software Project Management Framework

Characteristics of projects:

Project has a customer/sponsor

i.e. direct beneficiary from the project success
It has stakes and stakeholders
It has definable inputs, control parameter, purpose or end-product.
e.g. cost, schedule, performance
It is unique (as against routine)
It is temporary in nature
It evolves as it progresses
It involves an element of unfamiliarity
It involves uncertainties and risks
It is a process of working to achieve the goals
It require varied resources
It has defined start and finish dates.

What is project management?

Project management involves application of knowledge, skills, tools and techniques to the
project activities with the objectives of meeting or exceeding the stakeholder
expectations.
Project management requires ability to administer a project by balancing the team and
technology.
Team

Schedule

Technology

Cost

Resources

Performance

Profit

Productivity

Project and product-oriented processes

Process is a set of interrelated actions that are performed to achieve a predefined set of
products, services or results.
Project processes are performed by the project team.
Perprocesses broadly fall into two categories:
Project
Project management processes: these are directed at initiating, planning,
executing, monitoring, controlling and closing a project.

Page 13 of 22

Product-oriented processes: these processes are typically defined by the project life
cycle.
Project management processes and product-oriented processes overlap and interact with
each other throughout the project life.
Processes interact with each other in complex ways
They also interact in relation to scope, cost, schedule etc.

Components of a process
Process

Product Engineering
Process

Process Management
Process

Product Development
Process

Project Management
Process

Overlap Amongst process groups

It is 2-dimentional graph, given in the classroom

Project Charter
A document that formally recognizes the existence of a project.
Provides the PM with the authority to apply organizational resources to the project: what the
PM can and cannot do.
e.g.; Right to reset Plan when requirements are changed
Defines the project goal, scope and objectives.
Details the level of quality to be expected.
Validates the business justification.
Highlights risk.
Its the contract: if anything needs resolution, this should specify it
When in doubt, read the Charter!
Also specifies:
what to do if there is conflict
Management reconciliation
Scope change management
Knowledge transfer
Training approach
Anything else

Page 14 of 22

Software Project Planning

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?
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?
Page 15 of 22

 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?
Step 4 Identify project products and activities
4.1 Identify and describe project products - what do we have to produce?

Page 16 of 22

4.2 document Generic product flows

Step 4.3 Recognize product instances

The PBS and PFD 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
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

Page 17 of 22

An ideal activity

Step 4.5 Add check-points if needed

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
Page 18 of 22

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

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
This may require the reiteration of the planning process at a lower level
Page 19 of 22

Software Project Estimate

A successful project is one delivered on time, within, budget and with required quality.
This implies that targets are set which the project manager then tries to meet.
A project manager has to produce estimates of effort which affects costs, and of activity duration,
which affect the delivery time.
Some of the difficulties of estimating time arise from the complexity and invisibility of the
software. Also the intensely human activities which make up system development cant be
treated in a purely mechanistic way.
Other difficulties include:
1. Subjective nature of estimating
2. Political implications
3. Changing technology
4. Lack of homogeneity of project experience

What are estimates done?

Estimates are carried out at varies stages of software project for a variety of reasons:
1. Strategic planning
2. Feasibility study
3. System specification
4. Evaluation of suppliers proposal
5. Project palnning

Over and under-estimating

Parkinsons Law: Work expands to fill the time available

An over-estimate is likely to cause project to take longer than it would otherwise
Weinbergs Zeroth Law of reliability: a software project that does not have to meet a
reliability requirement can meet any other requirement

Software effort estimation techniques

Barry Boehm, in his classic work on software efforts models, identified the main ways of deriving
estimates of software development efforts as:
Algorithmic models, which use effort drivers representing characteristics of the target
system and the implementation environment to predict effort;
Export judgement, based on the advice of knowledgeable staff;
Analogy, where a similar, completed, project is identified and its actual effort is used as
the basis of the estimate;
Parkinson, where the staff effort available to do a project becomes the estimate
Price to win, where the estimate is a figure that seems sufficient low to win a contract;
Top-down, where an overall estimate for the whole project is broken down into the effort
required for component tasks;
Bottom-up, where component tasks are identified and sized and these individual
estimates are aggregated.
Page 20 of 22

A taxonomy of estimating methods

Bottom-up - activity based, analytical

Parametric or algorithmic models e.g. function points
Expert opinion - just guessing?
Analogy - case-based, comparative
Parkinson and price to win

Bottom-up versus top-down

Bottom-up
use when no past project data
identify all tasks that have to be done so quite time-consuming
use when you have no data about similar past projects
Top-down
produce overall estimate based on project cost drivers
based on past project data
divide overall estimate between jobs to be done

Bottom-up estimating
1. Break project into smaller and smaller components
2. Stop when you get to what one person can do in one/two weeks]
3. Estimate costs for the lowest level activities
4. At each higher level calculate estimate by adding estimates for lower levels

Top-down estimates

Algorithmic/Parametric models

COCOMO (lines of code) and function points examples of these

Problem with COCOMO etc:

Page 21 of 22

Examples of system characteristics

no of screens x 4 hours
no of reports x 2 days
no of entity types x 2 days
the quantitative relationship between the input and output products of a process can be
used as the basis of a parametric model

Parametric models - the need for historical data

simplistic model for an estimate
estimated effort = (system size) / productivity
e.g. system size = lines of code
productivity = lines of code per day
productivity = (system size) / effort based on past projects

Parametric models

Some models focus on task or system size e.g. Function Points

FPs originally used to estimate Lines of Code, rather than effort

Other models focus on productivity: e.g. COCOMO

Lines of code (or FPs etc) an input

Page 22 of 22