SOFTWARE
PROJECT
MANAGEMENT
By DR.S.Santhosh baboo
PROJECT:
The dictionary definition put a clear
emphasis on the project being a planned activity
The characteristic which distinguish project
as
Non routine task are involved
Planning is required
Specific objectives are to be met
Work is carried out for someone other than
yourself
Work involves several specialisms
Work is carried out in several phases
The project is large
The resources are available for use on the
project are constrained
MANAGEMENT:
Management involves following activities:
Planning –deciding what to be done
Organizing-making arrangement
Staffing-selecting right people for right job
Directing-giving instruction
monitoring-checking on progress
Controlling-taking action to remedy holdups
Innovating-coming up with new solution
Representing-liasing with clients, users,
developers, suppliers and stakeholders
MANAGING SOFTWARE
PRODUCT:
Worldwide, some half a million project
managers execute about a million software projects
each year, producing software worth $600 billion.
Many of these projects fail to fulfill customers‘
quality expectations or fail to deliver the software
within budget and on schedule. One analysis
suggests that1about one-third of projects have cost
and schedule overruns of more than 125%.
Why do so many software projects fail?
Although there are many reasons, one of the
most important is improper management of the
project.
PROCESS AND
MANAGEMENT CONCEPTS:
A software project has two main activity
dimensions: engineering and project management.
The engineering dimension deals with building the
system and focuses on issues such as how to
design, test, code, and so on. The project
management dimension deals with properly
planning and controlling the engineering activities
to meet project goals for cost, schedule, and
quality.
PROJECT MANAGEMENT
PROCESS:
For a project team to successfully execute a
project, it must perform hundreds of tasks, many
of them interdependent. Effectively managing this
process is extremely important for success. At
software companies, the set of activities executed
by a project manager is specified in the project
management process.
It is fairly standard, having three main stages:
Project planning
Project execution
Project closure
PROBLEM WITH
SOFTWARE PROJECT:
 Poor estimation and plain
 Lack of quality of standard and measurement
 Lack of guidance about making organizational
decisions
 Lack of techniques to make process visible
 Poor roll definition
STAKEHOLDERS:
people who are having a stake or interest in
the project. It is important that they be identified
as possible, be cause you need to communicate
channel with right from the start.
REQUIRED
SPECIFICATION:
 Functional requirement
 Quality requirement
 Resource requirement
STEP WISE PROJECT
PLANNING:
0.Select Project
1.Identify scope and
objectives
2.Identify project
infrastructure
3.Analyse project
characteristics
4.Identify products
and activities
5.Estimate effort for
each activity
6.Identify activity risks
7.Allocate resources
8.Review plan
9.Execute plan
STEP 0:
select the project
Step 1:
 Identify the project scope
and objectives.
identify the object and measurement of
effectiveness in meeting them.
establish a project authority
identify stake holders
Step 2:
Identify the project infrastructure
Establish relationship between project
and strategic planning
Identify installation standards and
procedure
Identify the project team organization
Step 3:
Analyses the project characteristic
Distinguish the project as either objective or
product driven
Analyses other project characteristic
Identify the high level project risk
Take into account user requirements
concerning implementation
Select general life cycle approach
Review overall resource estimation
Step 4:
identify the product and the activities
Identify and describe project products
Document the generic product flows
Recognize the product instance
Product deal activities network
Modify deal to take into account need
for stages and check point
Step 5:
estimate effort for each activities
Carryout the bottom up estimation
Revise plan to create controllable
activities
Step 6:
identify the activity risk
Identify and describe quantify activity
based risks
Plan risk reduction and contingency
measures where appropriate
Adjust plans and estimates to take
account of risks
Step 7:
Allocate resources
Identify and allocate resources
Revise plans and estimates to take
account of resource constraints
Step 8:
Review/publicize plan
Review quality aspects of project plan
Document plans and obtain agreement
Step 9/10:
Execute plan/lower level of planning
This may require the reiteration of the
planning process at a lower level.
SELECT THE PROJECT:
 Deciding whether the project can be taken up or
not
 Technical,Organizational and Financial
Feasibility is considered
 Programme Management Group of projects
managed in a coordinated way to gain benefits.
DIFFERENT FORM OF
PROGRAMME:
 Strategic Programmes
 Business cycle programmes
 Research and development programmes
PROGRAM MANAGEMENT
AND PROJECT
EVALUATION :
Program management
Managing the allocation of resources within
programs
Strategic program management
Creating a program
Aids to programme management
Beneficial management
Technical assessment
Evaluation of individual projects Cast-benefit
analysis
Cash flow forecasting
Cost benefit evaluation techniques
Risk evaluation
STRATEGIC PROGRAMMES:
 Several projects implement single strategy]
 Two Organizations  Unified Payroll
 The Projects are coordinated and done according
to the strategy
BUSINESS CYCLE
PROGRAMMES:
 Specific budget for the projects
 If one project is delayed, staff from other team
can be used and resources also can be used
RESEARCH AND DEVELOPMENT
PROGRAMMES:
 New innovative ideas to develop new products
 High risk if successful result is good
CREATING A PROGRAMME:
 The Programme Mandate
 The Programme Brief
 The Vision Statement
 The Blue Print
THE PROGRAMME
MANDATE:
Formal document describing
New services programme should deliver
How organization will be improved by
new services
Programme director provides initial
leadership
THE PROGRAMME BRIEF:
 Information sufficient to decide about
project(vision statement)
 Estimates cost,performance and risk
BLUE PRINT:
 Organizational structure(staffs and skills)
 Resources
 Data and information requirements
IDENTIFY PROJECT SCOPE
AND OBJECTIVES:
Scope and Objectives of the project are
Constraints
Meet requirements
Cost control
Identify stake holders and their interest
Communication
IDENTIFY PROJECT
INFRASTRUCTURE:
 Project should fit in existing infrastructure
 Project manager should have full control over the
project
 Project Manager should be aware of Project
planning and control
SELECTION OF AN
APPROPRIATE PROJECT
APPROACH:
Choosing technologies
Technical plan contents list
Choice of process models
Structure versus speed of delivery
The waterfall model
Spiral model
Software prototyping
Incremental delivery
Dynamic system development
Extreme programming
Managing iterative processes
Selecting a most appropriate process model
PROJECT ANALYSIS:
 Outcome of analysis will be selection of most
appropriate methodologies and technologies
 Methodologies(Unified Software Development
Process (USDP), Structured system analysis and
design methods (SSADM))
 Technologies(Environments , Software etc)
STEPS IN PROJECT
ANALYSIS:
Identify project as either objective driven or product
driven
Analyses Project Characteristics
Data driven or Process driven
General tool or application specific
Specific tools available(Graphics etc)
Hardware and software environment
Entertaining games or servicing
CHOICE OF PROCESS
MODELS:
 The activities can be organized in different ways
known as models(Process Models)
 The various models are
Waterfall Model
V Process Model
Spiral Model
WATER FALL MODEL:
Feasibility study
User Requirements
Analysis
System design
Program design
Coding
Testing
Operation
V-PROCESS MODEL:
User acceptance
Feasibility study
User acceptance
User requirements
System design
System testing
Program design
Code
Program testing
SOFTWARE EFFORT
ESTIMATION:
 The definition of successful project is
delivering the project on correct time within
the budget at good quality
 Hence estimation such as Lines of
Code,Number of months have to be done
 Estimates are carried out at various stages of
the project
BASIS FOR SOFTWARE
ESTIMATION:
 Need of historical data(past projects)
 Measure of work(Lines of code)
 Complexity(varies with the project)
EFFORT ESTIMATION
TECHNIQUES:
 Function point method
 Empirical model method
FUNCTION POINT METHOD:
 The measures are collected by means of various
functions such as
 Number of user inputs
 Number of user outputs
 Number of user inquiries
 Number of files
 Number of external interfaces
EMPIRICAL MODEL METHOD:
Cocomo Model(COnstructive COst MOdel)
This model deals with sizing information such as
number of screens, number of reports etc.
The Productivity rate is determined from which the
effort in months is calculated
RISK MANAGEMENT










Risk
Categories of risk
A framework for dealing with risk
Risk identification
risk assessment
Risk planning
Risk management
Evaluating risk to scheduling
Critical chain concepts
conclusion
RISK MANAGEMENT:
 Risk is an uncertain event or condition that if
occurs has positive or negative effect on a
project’s objectives
 Key elements of risk are
 1. It relates to the future
 2. It involves cause and effect (Cost, Staff)
CATEGORIES OF RISK:
 Project Risk(Objectives)
 Business Risk(Cost)
 Social Technological
Risk(Staff,Technology,Tasks)
RISK DEALING:
 Risk Identification
 Risk Analysis and Prioritization
 Risk Planning
 Risk Monitoring
RISK IDENTIFICATION:
 Use of Checklists and Brainstorming
 Checklists refer to the number of risks that occur
regularly in development of project
 Brainstorming uses stakeholders to identify risks
and find a solution to the problems
CHECKLISTS:
Risk
1.Personnel shortfalls
2.Unrealistic time and cost estimates
3.Late changes to requirements
4. Technical problem
5.Developing wrong software functions
BRAINSTORMING:
 The stakeholders together identify the risks and
identify possible solutions to overcome the risk.
 The main stakeholders are considered for risk
identification
RISK ANALYSIS AND
PRIORITIZATION:
The risk is potentially endless hence the risk
exposure should be calculated by the following
formula
Risk Exposure=Potential damage*Probability
of occurrence
The risk exposure can be calculated for all sort of
risks in the checklist
RISK PLANNING:
 The risks are identified and prioritized, then
decision should be taken to deal with the risk
 The choices are
1.Risk Acceptance
2.Risk Avoidance
3.Risk Reduction and Mitigation
4.Risk Transfer
RISK PLANNING:
 Risk Acceptance  Some risks can be ignored,
some risks have to be solved
 Risk Avoidance  The risks should be avoided
before itself(Staff,Technology etc)
 Risk Reduction Take precautions to reduce the
risk
 Risk Transfer  The project can be transferred to
other organization who are experienced
RISK MONITORING:
 The steps for risk reduction should be
implemented and monitored in this stage
 The Project Manager should monitor the risks
carefully by means of documents and register it.
 The evaluation of risk management should be
done to see how the risk is reduced.
RESOURCE ALLOCATION:
 Nature of resources
 Identifying resource requirements
 Scheduling resources
 Creating a critical path
 Counting the cost
 Being specific
 Publishing the resource scheduling
Cost schedules
The scheduling sequence
conclusion
RESOURCE ALLOCATION:
The resource is an item or staff required to
complete a project.
The various categories of resources are
1.Labour
2.Equipment
3.Materials
4.Space
5.Services
6.Time
7.Money
IDENTIFYING RESOURCE
REQUIREMENTS:
 Resource allocation plan to know about the
demand
 Each activity is considered to identify the
resources allocated
SCHEDULING RESOURCES:
 The resources are scheduled according to the
priority.The resource which is needed
immediately is allocated first
 The resource scheduling is done according to the
modules
 The resource availability is seen and then only
scheduled.
8.MONITORING AND
CONTROL:
 Creating the framework
 Collecting a data
 Visualizing process
 Cost monitoring
 Earned value analysis
 Prioritizing monitoring
 Getting a project back to target
 Change control
 conclusion
MONITORING AND MANAGE
CONTROL:
 The progress of the project is monitored as it is
under the way after resource allocation
 The control is established through the project
control cycle
The steps in the cycle are
Start
Publish initial plan
Gather project information
Compare progress vs targets
If satisfactory continue else revise and start from
step 3
If project completed continue else goto step 3
End project and review
Give document conclusions
CATEGORIES OF
REPORTING:
 Oral Formal Regular(Weekly Meetings)
 Oral Formal AdHoc(End stage Revies)
 Written Formal Regular(Jobsheets,Progress
Reports)
 Written Formal AdHoc(Change Reports)
GUIDELINES:
• Risk Management
• Cost Management
• Resource Management
MANAGING CONTRACT:
 The ISO12207 approach to the acquisition and
supply of software
 The supply process
 Types of contract
 Stages in contract placement
 Typical terms of contract
 Contract management
 Acceptance
 conclusion
MANAGING PEOPLE AND
ORGANIZING TEAMS:
 Understanding behavior
 Organization behavior
 Selecting a right person for right
job
 Instruction in best methods
 Motivation
 Working in groups
 Becoming a team
 Decision making
 Leadership
 Organizational structures
RECRUITMENT PROCESS:
 Create a job specification(Requirements)
 Create a job holder profile
 Obtain Applicants(Advertisement)
 Examine CV`s
 Conduct of Interviews
 Other Procedures(Medical Examination)
ORGANIZING TEAMS:





The stages of development for forming a team
Forming(Know each other,stick on to rules)
Storming(Method of operation to avoid conflicts)
Norming(Group entity settled and no conflicts)
Performing(Tasks emphasized)
Adjourning(Group starts their work)
SOFTWARE QUALITY:
 The place of software quality in
project planning
 Importance of software quality
 Defining a software quality
 Practical software quality
measure
 Product versus process quality
management
 External standards
 Techniques to help enhance software quality
 Quality plan
 conclusion
SOFTWARE QUALITY:
 Quality is defined as “How well the project
performs as we have planned”
 Quality is concerned at various stages of planning
and execution
SOFTWARE QUALITY
MEASURES:
 Reliability
 Maintainability
 Extendibility
SOFTWARE QUALITY
MANAGEMENT SYSTEM:
– Quality Assurance
• Through this process an org. establishes
procedures and standards that lead to the
development of high quality software
– Quality Planning
• Involves selection of appropriate procedures and
standards for a project that will deliver quality
software
• Sets the direction for the quality process- without
clear spec. regarding desired quality of the
product
– Quality Control
• Ensures that selected procedures are
followed throughput the project.
MEASURING SOFTWARE
QUALITY:
 The first step towards measurement is to identify
software metrics
 Metrics is defined as ‘a quantitative measure of
the degree to which a system, component or
processes a given attribute’ –i.e., It involves
collection of data over a period of time that gives a
measure of performance
Three reasons for which you need to measure a
software system:
 To determine the quality of the product and
development process in relation to expected
standards.
 To predict the qualities that the product will
exhibit in future in relation to expected standards
 To improve the quality of the product and the
process that produced it
WHAT ARE SOFTWARE
REVIEWS? WRITING THE
SOFTWARE SPECIFICATION
Everyone knew exactly
what had to be done
until someone wrote it
down!
OBJECTIVES OF REVIEWS:
 Uncover errors in any representation of software
 Verify that
software meets its requirements
software follows predefined standards
software is developed in uniform manner
 Make projects more manageable
 Educate new team members
HOW TO CARRY OUT
REVIEWS:
THE REVIEW TEAM
producer
review
leader
reviewer(s)
recorder
BASIC GUIDELINES (1)
 3-6 people (typical)
experienced senior technical staff
representatives of
team that created the document
client representative
team for next development phase
software quality assurance group
 IEEE Standard for Software Reviews and Audits
[IEEE 1028, 1988]
BASIC GUIDELINES (2)
 Review leader should be SQA representative
has the most to lose
creator: eager to get approval (to start next job)
client: can wait for acceptance testing
 Review leader distributes material
 Advance preparation of max. 2 hours before the
meeting
 Duration: less than 2 hours
RESULT OF A REVIEW:
 Decision about the product
accept without further modification
reject the work due to severe errors (review
must be repeated)
accept with minor modifications (that can be
incorporated into the document by the
producer)
 All participants have to sign-off
shows participation responsibility
shows their concurrence with the findings
REVIEWER’S PREPARATION:
 be sure that you understand the context
 first, skim all the product material to understand
location and format of the information
 next, read product material and annotate hardcopy
 pose your written comments as questions
 avoid issues of style
 inform the review leader if you can’t prepare
CONDUCTING THE REVIEW
 Be prepared - evaluate product before review
 develop check list for each kind of work product
 review the product, not the producer
 keep your tone mild, ask questions instead of
making accusations
 stick to the review agenda
 raise issues, don’t resolve them!
 limit discussions (do them off line!)
 avoid discussions of style - stick to technical
correctness
 schedule reviews as project tasks (allocate
resources)
 record and report all review results
QUALITY MANAGEMENT
SYSTEM
•
•
•
•
•
•
•
•
Processes
Standards
Techniques
Guidelines
Templates
Checklists
Forms
Document structure and Update Prcedure
QUALITY MODEL
 ISO 9000 Model
 Software Engineering Institute Model
ISO 9000 STANSARDS:
 ISO 9000 : model for qlty. assurance in
design/development, production, installation and
servicing
 ISO 9002 : model for qlty. assurance in production
and installation
 ISO 9003 : model for qlty. assurance in final
inspection and test
ISO 9000
 ISO (international Standards Organization):
– Consortium established to formulate and foster
standardization.
 ISO published its 9000 series of standards in 1987.
What is ISO 9000 Certification?
 ISO 9000 certification:
serves as a reference for contract between
independent parties.
 The ISO 9000 standard:
specifies guidelines for maintaining a quality
system.
 ISO 9000 specifies:
guidelines for repeatable and high quality
product development.
Also addresses organizational aspects
responsibilities, reporting, procedures,
processes, and resources for implementing
quality management.
ISO 9000 Certification
 An ISO certified organization
can use the certificate for corporate
advertisements
cannot use the certificate to advertise products.
ISO 9000 certifies organization's process
not any product of the organization.
An organization using ISO certificate for
product advertisements:
risks withdrawal of the certificate.
Summary of ISO 9001
Requirements:
 Management responsibility(4.1):
Management must have an effective quality
policy.
The responsibility and authority of all those
whose work affects quality:
 must be defined and documented.
Management responsibility:
 Responsibility of the quality system.
independent of the development process,
can work in an unbiased manner.
 The effectiveness of the quality system:
must be periodically by audited.
Quality system and contract
reviews
 A quality system must be maintained and
documented.
 Contract reviews (4.3):
Before entering into a contract, an organization
must review the contract
ensure that it is understood,
organization has the capability for carrying
out its obligations.
Design control:
 The design process must be properly controlled,
this includes controlling coding also.
 A good configuration control system must be in
place.
 Design inputs must be verified as adequate.
 Design must be verified.
 Design output must be of required quality.
 Design changes must be controlled.
Document control:
 Proper procedures for
document approval, issue and removal.
 Document changes must be controlled.
use of some configuration management tools is
necessary.
Process Control:
 The development must be properly managed.
 Quality requirements must be identified in a
quality plan.
Inspection and Testing:
In software terms this requires effective
testing i.e.,
unit testing, integration testing and system
testing.
Test records must be maintained.
Corrective Action:
 This is both about correcting errors when found,
investigating why they occurred
improving the process to prevent further
occurrences.
 If an error reoccurs despite the quality system,
the system needs improvement.
Handling and Quality audits:
 Handling Deals with:
storage, packing, and delivery of the software
product.
 Quality Audits :
quality system audit must be carried out to
ensure its effectiveness.
Salient features of ISO 9001
requirements:
 All documents concerned with the development of
a software product
should be properly managed, authorized, and
controlled.
 Proper plans should be prepared
progress against these plans should be
monitored.
 Important documents independently checked and
reviewed:
 for effectiveness and correctness.
 The product should be tested :
against specification.
 Several organizational aspects:
e.g., management reporting of the quality team.
Shortcomings of ISO 9001
Certification:
 ISO 9000 requires a production process to be
adhered to:
but does not guarantee the process to be of high
quality.
Does not give any guideline for defining an
appropriate process.
Shortcomings of ISO 9001
Certification:
 ISO 9000 certification process
not fool-proof
no international accreditation agency exists.
likely variations in the norms of awarding
certificates:
among different accreditation agencies and
among the registrars.
SEI Quality Process
 Initial Level
 Repeatable Level
 Defined Level
 Managed Level
 Optimizing Level
SEI Capability Maturity Model:
 The SEI CMM classifies software development
industries into:
Five maturity levels.
Stages are ordered so that improvements at one
stage provide foundations for the next
Based on the pioneering work of Philip Crosby
SEI Capability Maturity Model:
Optimizing (5)
Managed (4)
Defined (3)
Repeatable (2)
Initial (1)
Level 1: (Initial)
 Organization operates
without any formalized process or project plans
 An organization at this level is characterized by
ad hoc and often chaotic activities.
Level 1: (Initial)
 Software production processes are not defined,
different engineers follow their own process
development efforts become chaotic.
The success of projects depend on individual
efforts and heroics.
Level 2: (Repeatable)
 Basic project management practices
tracking cost, schedule, and functionality are
followed.
 Size and cost estimation techniques
function point analysis, COCOMO, etc. used.
 Production process is ad hoc
not formally defined
also not documented.
 Process used for different projects might vary
between projects:
earlier success on projects with similar
applications can be repeated.
Opportunity to repeat process exist when a
company produces a family of products.
Level 3: (Defined)
 The process though defined,
process and product qualities are not measured.
 ISO 9001 aims at achieving this level.
 Management and development activities:
defined and documented.
Common organization-wide understanding of
activities, roles, and responsibilities.
Level 4: (Managed)
 Quantitative quality goals for products are set.
 Software process and product quality are
measured:
The measured values are used to control the
product quality.
Results of measurement used to evaluate
project performance
rather than improve process.
 Organization sets quantitative quality goals
 World-wide about 100 organizations assessed at
this level.
Level 5: (Optimizing)
 Statistics collected from process and product
measurements are analyzed:
continuous process improvement based on the
measurements.
Known types of defects are prevented from
recurring by tuning the process
lessons learned from specific projects
incorporated into the process
 Identify best software engineering practices and
innovations:
 tools, methods, or process are identified
transferred throughout the organization
 World-wide about 50 organizations have been
assessed at this level.
Key Process Areas
 Each level is associated with a key process area
(KPA) identifies
where an organization at the previous level
must focus to reach this level
Level 2 KPAs
 Software project planning
Size, cost, schedule.
project monitoring
 Configuration management
 Subcontract management
Level 3 KPAs
 Process definition and documentation
 Reviews
 Training program
Level 4 KPAs
 Quantitative measurements
 Process management
Level 5 KPAs
 Defect prevention
 Technology change management
 Process change management
CONCLUSION
 Hence the stepwise planning is necessary to
make the software project management
successful