PROJECT TIME AND COST

MANAGEMENT

by

Prof. Vijaya Desai

 Time, Cost Management
• Estimating time required to complete a task
• Estimating resources quantity and cost required
to complete a task in a given time
• Estimating task cost
• Creating task schedule using planning tools like
CPM, Gantt Chart, Milestone etc.
• Developing a base plan to monitor the actual
progress
• Analyzing the progress using EVA
Important elements in time and
effort estimation
• Size The Work
• Measure Your Velocity
• Dealing With Uncertainty
 Size The Work
• Sizing of work includes,
– Prediction of coding needed to complete the
work.
– Estimation of time required to complete the
work
– Estimation of effort needed to complete the
work
 Measuring Size of a software
• Size of a software can be defined or measured in terms of,
– Line of Code – LOC
– Function Points: represents to the business functionality in the
software.
Example: outputs, inquiries, inputs, internal files, and external
interfaces.
– Feature Points: represents the logic for a function.
– Number of bubbles on a DFD: one bubble refers to one entity in
the software system. Example 1, Example 2
– A count of process/control specifications (PSPECS/CSPECS) :
Refers to the computational process and validation control. Example
– Amount of documentation: technical documents, systems
documents, users documents.
– Number of objects, attributes, and services on an objects: refers
to fields in a table or object. Example
 Some facts and issues about LOC method
• Questions raised on LOC
– How do you know how many LOC before a software is
developed?
– Why should one believe the LOC is related to the efforts required
to develop a software before its development?
– How does LOC explain the work with newer programming
languages which have more intelligent logic building capability?
– How can a vast amount of LOC justify the work?
• In spite of the above questions LOC is widely used in measuring the
size of work in software development
• Despite the introduction of new languages, the productivity of a
programmer has remained to 3000 LOC per year for last 2 decades.
This simply shows size depend upon software functionality and
quality and not the number of LOC produces.
 Estimating LOC
• Using Expert Opinion and Bottom-Up Summations
– A detailed WBs is created.
– The size of each last level WBS is obtained by asking the
expert or potential developers who have developed similar
system.
– The number of size that is obtained is summed and is called
as “bottom-up” size estimate
– Sometimes the experts are asked to give three estimates such
as optimistic, pessimistic and most likely. PERT simulation
is used to obtain the time.
– Example: If an expert gives is opinion that development of
an input window would take between 200 to 400 lines, and if
he believe it may take optimally 250 lines then the
– LOC = [200+(250x4)+400/6] = 266 LOC
 Estimation of time for LOC

• Productivity is expressed in KSLOC/SM, where

KSLOC = thousands source LOC, SM = staff month
• Over the time the industry standard productivity
constants have been established for different
languages.
• These constants are then used to estimate the time
required to develop a software.
 Widely used methods of translating KSLOC in various
languages (thousands of line of code in one staff month)
Languages Basic assembler Average KSLOC
(Level) KSLOC Function Point
C 2.5 128-150
C++ 6 53
JAVA 6 53
Database languages (XML, 8 40
XQuery, Crystal Report)
Oracle developer/2000 14 23
SQL 25 13
Statistical languages 10 32
(Quantum, Analytica )

Basic assembler (Level) = Machine level code line

Refer to the following Book for other estimating
methods

”Quality Software Product

Management”

by

Robert T. Futrell,
Donald F. Shafer,
Linda I. Shafer
 Effort Estimation
• Effort is estimated after estimating the sixe of
the work
• Model to estimate Effort: COCOMO –
Constructive Cost Model
– Developed by Dr. Dennis Frailey
– Assumes that there are 19 productive staff-days per
staff-month and 152 staff-hours per staff-month.
– The above figures are arrived at by allowing for the
average number of vacation days and holidays in the
U.S. They would need to be modified for other
countries.
 COCOMO – Evolution of A
Regression Model
• Dr. Barry studies 63 software projects.
• The actual work size, actual effort and actual
schedule duration were analysed.
• He used the Regression analysis to find out the
relationship between the data points.
• He plotted the data on a scattered chart.
• He observed multiple equations lines evolving.
• Hence, he developed three modes that
categorizes the complexity of the system
 Scatter Plot
11
10
9
8
7
6
5
4
3
2
1
0
0 1 2 3 4 5 6 7 8 9 10 11
 Three Modes of COCOMO
• Organic Mode: Systems have small project team, little
innovation, less deadlines and constraints, development
environment is stable. Example: payroll, inventory
• Semidetached Mode: Systems have medium-size project team,
some innovation needed, moderate deadlines and constraints,
development environment is little fluid
Example: Utility systems such as compilers, database system,
anti-virus system
• Embedded: Systems are real time, large project team, great
innovation needed, deadlines and constraints are tight, complex
interfaces – with hardware and software
Example: real-time systems such as traffic control, e-business
systems, ATM
 Levels of COCOMO

• Basic level
• Intermediate level
• Detailed Level
 Levels of COCOMO - Basic
• Basic Level: uses size and mode to determine
the effort and schedule.
• Useful for fast, rough estimate of small to
medium-size project
• Formula
– Effort (E) = a x (Size)b
– a and b = constants derived from regression
analysis (depends on the project)
– Size = thousands of lines of code (KLOC)
– E = effort expressed in staff-months
 Levels of COCOMO - Intermediate
• Intermediate Level: Uses, size, mode, and 15
additional variables to determine the effort.
• Additional variables are cost drivers relater to
product, personnel, computer and project
attributes (business function) that result into
increase or decrease of effort.
• The product of the cost drivers is known as
Environmental Adjustment Factor (EAF)
• Formula:
Effort (E) = a x (Size)b x C, where C = EAF
 Levels of COCOMO - Detailed
• Detailed Level: builds upon intermediate
COCOMO level by introducing additional
capabilities of software called as cost drivers.
• Detailed COCOMO incorporates all
characteristics of the intermediate version with an
assessment of the cost driver's impact on each
detailed phase of project (plan and
requirement, system design, detailed design,
module code, and test, integration and test,
etc.) of the software engineering process.
 Estimation of Project Duration
• The formula is devised in the same way as that of
effort calculation thus giving rise to coefficient c
and d
• The duration calculated is called as
Time to develop = TDEV
• Formula
TDEV = c x (E)d
 The values of coefficients a, b, c and d
used in calculating effort (a, b), time (c, d)
– for Basic level

Software project a b c d
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
 Estimation of
Effort, Time and Staff for a project

Example 1
Example 2
 Intermediate COCOMO Mode
• The mode works same as that of basic mode,
plus 15 additional variable called cost drivers are
taken into account.
• It uses size, cost driver ratings to estimate the
effort.
• Formula for Effort
– E = a x (Size) b x C
– Where C = cost driver rating
 Intermediate COCOMO Formula for Effort
• Organic Mode, E = 3.2 x (Size) 1.05 x C
• Semidetached Mode, E = 3.0 x (Size) 1.12 x C
• Embedded Mode, E = 2.8 x (Size) 1.20 x C
• C = cost driver rating
• C is calculate by taking the product of all Cost drivers.
• Product of Cost Drivers is called as
Effort Adjustment Factor (EAF)
Therefore EAF = C
• EAF = C1 x C2 x ….. X Cn
• If C = 1 implies the cost driver does not apply
• If C > 1 implies increased cost due to this factor
• If C < 1 implies decreased cost due to this factor
 The values of coefficients a, b, c and d
used in calculating effort (a, b), time (c, d)
– for Intermediate level projects

Software project a b
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
Intermediate COCOMO Cost Driver Categories
Product Computer Personnel Project
Required Software Execution Time Analyst Capability Use of Modern
Reliability (RELY) Constraints (ACAP) Programming
(TIME) Practices (MODP)
Database Size Main Storage Application Use of Software
(DATA) Constraint (STOR) Experience Tools (TOOL)
(AEXP)
Product Virtual Machine Programmer Required
Complexity Volatility (VIRT) Capability (PCAP) Development
(CPLX) Schedule (SCED)
Computer Virtual Machine
Turnaround Time Experience
(TURN) (VEXP)
Programming
Language
Experience
(LEXP)
Effort Adjustment Factor
(EAF) = C
C = RELY x DATA x CPLX x
TIME x STOR x VIRT x TURN x
ACAP x AEXP x PCAP x VEXP x
LEXP x MOCP x TOOL x SCED
 Effort Estimation using
Intermediate COCOMO Model
Example 1
Example 2
 Resources in a software project
• Identify the Types of roles: refers to type of work a resource
has to perform
– Database designers
– Configuration management experts
– Human interface designers
– Webmasters
– Quality assurance (QA) specialists
– Network specialists
– System architects
– Programming language experts (C, C++, Java etc.)
– Test engineers
• Identify the type of skill a resource has to perform
– Worker – Responsible to execute the scheduled work
– Supervisor – Authority to perform, command of scheduled work
– Manager – Accountable of liability for an activity or something value in a
project
Methods for selecting projects
1. Based on Criteria - Weighted scoring model
• To focusing on Broad organizational need
• To solve a problems
• To create new business opportunities
• To create directives

2. Based on Financial Analysis

• Net Present value analysis
• Returns on Investment (ROI)
• Payback analysis
 Net Present value analysis
Is a method of calculating the expected net monetary gains or
loss from a project by discounting all expected future
cash inflows and outflows.

 Projects with + ve NPV should be considered if financial

value is the key criteria
 + ve NPV means the returns from a project exceeds the
cost of capital that is the returns available by investing the
capital elsewhere
 Projects with higher NPVs are preferred to projects with
lower NPVs, if all other things are equal.
 Steps to determine NPV
 Determine the cash inflows and outflows for the project
 Determine the discount rate = minimum acceptable rate of
return on an investment
 Calculate NPV
 use of spreadsheet
NPV = npv (discount rate, range of cash flows)
 Mathematical formula

or

Where
Co: Initial investment made at the beginning of the project.
t = year of cash flows
A = amount of cash flow each year
r = discount rate
Example of Cash flows
 NPV examples
Discount rate =10%
Project 1 Year1 Year2 Year3 Year4 Year5 Total
Benefits 0 2000 3000 4000 5000 14000
Costs 5000 1000 1000 1000 1000 9000
Cash flows (5000) 1000 2000 3000 4000 5000
NPV 2316
Project 2 Year1 Year2 Year3 Year4 Year5 Total
Benefits 1000 2000 4000 4000 4000 15000
Costs 2000 2000 2000 2000 2000 10000
Cash flows (1000) 0 2000 2000 2000 5000
NPV 3201
Figures in Rs.

Recommend Project 2 because it has higher NPV

 Return on investment (ROI)
 Is income divided by investment.
ROI = (total discounted benefits – total discounted
costs)/discounted costs
 Example:
today's investment (costs) = Rs. 100
next year worth (benefits) = Rs. 110
ROI = (110-100)/100=0.1 or 10 %
 yearly discounted costs = discount factor * cost of the year
discount factor = 1/(1+r)t, where r= discount rate, t= year
 The higher ROI, the better
 Calculation of ROI
Discount rate =10%
Project 1 Year1 Year2 Year3 Year4 Year5 Total
Costs (5000) (1000) (1000) (1000) (1000) -9000
Discount factor =0.91 = 0.83 = 0.75 = 0.68 = 0.62
Discounted Costs -4545 -826 -751 -683 -621 -7427

Benefits 0 2000 3000 4000 5000 14000

Discount factor =0.91 = 0.83 = 0.75 = 0.68 = 0.62
Discounted Benefits 0 1653 2254 2732 3105 9743
ROI = 31%
[(total discounted benefits – total discounted costs) /
discounted costs]

Note: Figures in Rs. Assume that the costs are negative

 Calculation of ROI
Discount rate =10%
Project 2 Year1 Year2 Year3 Year4 Year5 Total
Costs (2000) (2000) (2000) (2000) (2000) -10000
Discount factor =0.91 = 0.83 = 0.75 = 0.68 = 0.62
Discounted Costs -1818 -1653 -1503 -1366 -1242 -7582

Benefits 1000 2000 4000 4000 4000 15000

Discount factor =0.91 = 0.83 = 0.75 = 0.68 = 0.62
Discounted Benefits 909 1653 3005 2732 2484 10783
ROI = 42%
[(total discounted benefits – total discounted costs) / discounted
costs]

Note: Figures in Rs. Assume that the costs are negative

 Payback Analysis
 Payback period is the amount of time it will take to recoup,
in the form of net cash inflows
 Determines how much time will lapse before accrued
benefits overtake accrued and continuing costs.
 Payback occurs when cumulative discounted benefits and
costs are greater than zero
Discounted benefits + Discounted Cost >0
 Payback Analysis for Project 1
Discount rate =10%
Project 1 Year1 Year2 Year3 Year4 Year5 Total
Costs (5000) (1000) (1000) (1000) (1000) -9000
Discount factor =0.91 = 0.83 = 0.75 = 0.68 = 0.62
Discounted Costs -4545 -826 -751 -683 -621 -7427

Benefits 0 2000 3000 4000 5000 14000

Discount factor =0.91 = 0.83 = 0.75 = 0.68 = 0.62
Discounted Benefits 0 1653 2254 2732 3105 9743

Discounted benefits + costs -4545 826 1503 2049 2484 2316

Cumulative benefits + costs -4545 -3719 -2216 -167 2316 4633
ROI = 31%
Payback in this year

Note: Figures in Rs. Assume that the costs are negative

 Payback Analysis for Project 2
Discount rate =10%
Project 2 Year1 Year2 Year3 Year4 Year5 Total
Costs (2000) (2000) (2000) (2000) (2000) -10000
Discount factor =0.91 = 0.83 = 0.75 = 0.68 = 0.62
Discounted Costs -1818 -1653 -1503 -1366 -1242 -7582

Benefits 1000 2000 4000 4000 4000 15000

Discount factor =0.91 = 0.83 = 0.75 = 0.68 = 0.62
Discounted Benefits 909 1653 3005 2732 2484 10783

Discounted benefits + costs -909 0 1503 1366 1242 3201

Cumulative benefits + costs -909 -909 594 1960 3201 6403
ROI = 42%
Payback in this year

Note: Figures in Rs. Assume that the costs are negative

NPV, ROI and Payback period -
A CASE on E-business Project
 Weighted Scoring Model
 Provides a systematic process for selecting projects on many criteria
 The criteria include factors like meeting broad organizational needs,
addressing problems, opportunities or directives
 Steps in creating a weighted scoring model
 Identify criteria important to project selection
 Examples: supports key business objectives
 Has strong internal sponsor
 Has strong customer support
 Uses realistic level of technology
 Can be implemented in one year or less
 Provides positive net present value
 Has low risk in meeting scope, time, and cost goals
 Assign a weight to each criteria based on how mush value and
importance to be given to the criteria. Total of all the criteria must be
100.
 Assign numerical scores to each criterion (from 0 to 100) for each
project
 Weighted discount for a project = sum of product of weight and scores
of each criterion.
 Weighted Scoring Model
Criterion Weight Project Project Project Project
1 2 3 4
supports key business objectives 25% 90 90 50 20

Has strong internal sponsor 15% 70 90 50 20

Has strong customer support 15% 50 90 50 20

Uses realistic level of technology 10% 25 90 50 70

Can be implemented in one year or 5% 20 20 50 90

less
Provides positive net present value 20% 50 70 50 50

Has low risk in meeting scope, 10% 20 50 50 90

time, and cost goals
Weighted Project Scores 100% 56 78.5 50 41.5

Example
weighted score for project 1 = (25%*90) + (15%*70) + (15%*50) + (10%*25) +
(5%*20) + (20%*50) + (10%*20) = 56
 Weighted Score by project

90
78.5
80
70
60 56
50
50 41.5
40
30
20
10
0
Project1 Project2 Project3 Project4
 Corporate level Construction Project Management of a
client company like NHAI
NHAI

Entities
NH1 NH2 NH3
1. Client
2. Project
3. Contractor Contractor 1 Contractor 2 Contractor 4
4. Location
Contractor 3 Contractor 5

Location 1 Location 2 Location 3

Relationships
1. One project will have one location. One to one
2. Many contractors work on one project. Many to One
3. Many project Managers work on many projects. Many to Many
 Project Level Construction Database Entity and
Relationships for a Contractor
Project

Client Sub Sub Equipment Equipment

Contractor 1 Contractor 2 1 2

Locations 1 Locations 2 Task 1 Task 2

Entities
1. Project
Relationship
2. Client
1. One project one client: one-to-one
3. Sub Contractor
2. One Project Many Sub Contractor: one-to-many
4. Equipments
3. One Project many locations or sub projects: one-
5. Locations
to-many
6. Sub Projects
4. Many Equipments work on Many task: many-to-
7. Task
many
DFD model of Project for Daily Project Progress System

PROGRESS FILE

Last
Progress (LP)

Current Check task

Today’s
PROJECT Progress (TP) Progress (CP) schedule TASK INFORMATION
SITE Process FILE
CP=LP+TP
Tables; Columns or Attributes; Rows, Records, Tuples

Columns or
Attributes
Project Table

Project Project Client Location Project Project

ID Name Cost Duration

Pune01 Highway NHAI Pune- 25 12 months

Widening Satara

Pune02 Flyover Pune Pune- 14 8 months

Corp. University

Rows, Records, Tuples

• Use Case Specification : Transfer loan application to new responsible
• 1. Use Case Name: Transfer loan application to new responsible
• 1.1 Brief description
• The use case describes how a person responsible for a loan application can transfer it to another
• responsible.
• 2. Flow of Events
• 2.1 Basic Flow
• 1. The responsible notifies the system that he wants to transfer a specific loan application to
• another responsible.
• 2. The system displays the name of the applicant and the reference number of the
• application.
• 3. The responsible verifies that the application is correct based on the name of the applicant
• and the reference number.
• 4. The system presents a list of groups of responsibles and users within each group.
• 5. The responsible may choose one group of responsibles and possibly one particular
• responsible.
• 6. The responsible requests the loan application to be transferred to the chosen (group of)
• responsible(s).
• 7. The system transfers the application to the chosen (group of) responsible(s).
• The use case ends successfully.
• 2.2 Alternative Flows
• 2.2.1 The responsible cancels the transfer
• The responsible can cancel the transfer at any time and the use case ends.
• 2.2.2 Additional notification by mail
• After the 5th step:
• 5.1 The responsible indicates that the new responsible should receive an e-mail
telling
• him that he has received a new application for consideration.
• 5.2 The system automatically produces an e-mail message to the new
responsible.
• The use case resumes at step 6.
• Special Requirements
• 4. Pre-Conditions
• 4.1 The responsible must be logged on to the system
• The system must be started and the responsible must be logged on correctly.
• 5. Post-Conditions
• 5.1 The application has a valid status after saving
• The application should be saved in the database with a valid status and in a consistent
state.
• 5.2 The application is assigned to one responsible or to a group of responsibles
• The application should be assigned to one responsible or to a group of responsibles after
the
• transfer is completed.
• 6. Extension Points