FIT426. Project Management .

Lecture 7

COST MANAGEMENT
Cost and its Management
 Cost is resources expended to achieve a goal
 Usually measured in monetary units
 Cost management is the process to ensure project is
completed within budget
 Involves the following
 Estimating
 Budgeting, i.e., allocating resources
 Controlling
Basic Principles of Cost Management

 Most members of an executive board better

understand and are more interested in financial
terms than IT terms, so IT project managers must
speak their language
 Profits are revenues minus expenditures
 Profit margin is the ratio of revenues to profits
 Life cycle costing considers the total cost of ownership,
or development plus support costs, for a project
 Cash flow analysis determines the estimated annual
costs and benefits for a project and the resulting annual
cash flow

3
Table 7-1. Cost of Downtime for IT Applications

4
Types of ‘Costs’
 Tangible vs. intangible costs
 Direct vs. indirect costs
 Sunk costs
 Learning curve theory
 Items produced repetitively causes unit cost to drop
 Reserves
 Contingency
 Management
Estimating Costs
 Project managers must take cost estimates
seriously if they want to complete projects within
budget constraints
 It’s important to know the types of cost
estimates, how to prepare cost estimates, and
typical problems associated with IT cost estimates

6
Some problems with estimating
 Subjective nature of much of estimating
 Lots of guesswork - difficult to produce evidence
 Political pressures
 Managers may wish make estimates low to win support for
a project proposal
 Changing technologies
 these bring uncertainties can be a ‘learning curve’
 Projects differ
 Experience on one project may apply to another
Table 7-2. Types of Cost Estimates

8
Cost Management Plan
 Describes how to manage cost variances on
project
 Labor is usually the major costs
 Other costs are easier to estimate (why?)
 Methods of Estimation
 Top down
 Bottom up
 Parametric modeling
 Computer tools
Bottom-up estimating

1. Break project into smaller and smaller

components
2. Stop when you get to what one person can
do in two/one/half week
3. Estimate costs for the lowest level activities
4. At each higher level calculate estimate by
adding estimates for lower levels
Top-down estimates
2a. Price To Win
Estimate
overall  Produce overall
100 days
project estimate using effort
driver(s)
 distribute proportions
design code test of overall estimate to
components
30% 30% 40%
i.e. i.e. i.e. 40 days
30 days 30 days

11
Agile estimation
 Incremental development
 Break big project into smaller sections
 Timeboxes/sprints
 Develop in timeboxes = a FIXED amount of time
 Prioritisation
 Start with high priority tasks
 Just in time estimation
 Estimate at the right point in time/at right level
 Team estimation
 Get team involved
Expert judgement

 Asking someone who is familiar with and

knowledgeable about the application area and
the technologies to provide an estimate
 Particularly appropriate where existing code is
to be modified
 Research shows that experts judgement in
practice tends to be based on analogy
 Agile methods usually use individual/team
judgement
Estimating by analogy

Use effort
source cases
from source as
estimate
attribute values effort

attribute values effort target case

attribute values effort attribute values ?????

attribute values effort

attribute values effort

attribute values effort Select case

with closest attribute
values
Algorithmic/Parametric models

 COCOMO (lines of code) and function points

are examples of these
 Problem with COCOMO

guess algorithm estimate

but what is desired is

system algorithm estimate

characteristic
Lines of Code - LOC
 Standard measure of software size
 Will vary according to programming language
 Higher level languages produce less LOC (but it takes
longer to produce each LOC)
 Exactly what do you count? Executable code,
declarations, commentary, blank lines?
 May have more than one statement on a line
Function Points
 Measure the program features:
 external inputs and outputs
 user interactions
 external interfaces
 files used by system
 Assess each for complexity and give a weight between 3
(simple) - 15 (complex)
 Unadjusted function-point count UFC
 UFC = (number of elements) x (weight)
 Multiply UFC by factor based on overall complexity of project
(ie. performance, distributed use, reuse)
Function Points
 Language independent
 Complexity factors chosen subjectively
 Different people have different notions of complexity
– estimates can vary
 Some authors argue that useful in practice
 Can use to estimate LOC (tables)
Code size = AVC x no. function points
(AVC is a language-dependent factor varying from
200-300 for assembly language to 2-40 for a 4GL)
Algorithmic Cost Modelling
 Systematic approach to estimation
 Many different models – developed from empirical
studies of projects
Effort = A x SizeB x M

A is constant (type of software, org. etc)

Size is code size or functionality (measured in KLOC
thousands of lines of code)
B is exponential – costs increase with size
M is multiplier (dependent on process, product,
development attributes etc)
Effort in IT projects
 Effort is the total number of time units (e.g. weeks
or months) needed to complete the task.
 This may break down to effort from more than
one person, so as to take advantage of certain
skills and do jobs in parallel
 However:
 the more people one adds to a project the more one
needs to work so as to coordinate them and the more
they communicate so as to interact successfully, thus
yielding overheads.
COCOMO 2
 Best known cost model - COnstructive COst
MOdel
 Derived from empirical data
 Well-documented, in public domain, and
supported by a number of tools
 Has been widely used and evaluated
 Supports 3 levels – Early Prototyping, Early design,
Post-architecture
 Early design: Effort = A x SizeB x M + PMm
Estimating Staff Requirements
 Staff required can’t be computed by dividing the
development time by the required schedule
 The number of people working on a project varies
depending on the phase of the project
 The more people who work on the project, the more
total effort is usually required
 A very rapid build-up of people often correlates with
schedule slippage
Domain Specific Techniques
 Software applications
 COCOMO model
 Activity-based costing
 Other techniques
 Material take-off
 Expert opinions
 Engineering costs estimate
Typical Problems with IT Cost Estimates

 Estimates are done too quickly

 Lack of estimating experience
 Human beings are biased toward underestimation
 Management desires accuracy

24
Sample Cost Estimate
 See pages 265-270 for a detailed example of creating
a cost estimate for the Surveyor Pro project described
in the opening case
 Before creating an estimate, know what it will be used
for, gather as much information as possible, and
clarify the ground rules and assumptions for the
estimate
 If possible, estimate costs by major WBS categories
 Create a cost model to make it easy to make changes
to and document the estimate

25
Figure 7-2. Surveyor Pro Project Cost Estimate

26
Figure 7-3. Surveyor Pro Software Development
Estimate

27
Budgeting
 Involves allocating project cost (i.e., resources) to
individual work items
 WBS defines “work items”
 Goal to produce a cost baseline
 Cost baseline is
 Time phased budget
 Used by PM to monitor cost performance
Control
 Key task is to monitor expenditure
 Scope changes cost the project
 Stakeholders must know that changes in scope =
changes in cost baseline
 An approved change = revising cost baseline!
 And your reschedule as well!
 Moving one axis of your triple constraints change the
other dimensions
 Project managers must be meticulous!
Schedules
 Activity schedule - indicating start and completion
dates for each activity
 Resource schedule - indicating dates when
resources needed + level of resources
 Cost schedule showing accumulative expenditure
 Resources
 These include
 labour
 equipment (e.g. workstations)
 materials
 space
 services
 Time: elapsed time may be reduced by adding
more staff
 Money: used to buy the other resources
Resource allocation
 Identify the resources needed for each activity
and create a resource requirement list
 Identify resource types - individuals are
interchangeable within the group (e.g. ‘VB
programmers’ as opposed to ‘software
developers’)
 Allocate resource types to activities and examine
the resource histogram
 Resource histogram: systems analysts

5
STAFF REQD.

WEEK 1 2 3 4 5 6 7
Resource smoothing
 It is usually difficult to get specialist staff who
will work odd days to fill in gaps – need for staff
to learn about application etc
 Staff often have to be employed for a continuous
block of time
 Therefore desirable to employ a constant
number of staff on a project – who as far as
possible are fully employed
 Hence need for resource smoothing
 Resource smoothing

5
STAFF REQD.

WEEK 1 2 3 4 5 6 7 8
35
Resource clashes
 Where same resource needed in more than one
place at the same time
 can be resolved by:
 delaying one of the activities
 taking advantage of float to change start date
 delaying start of one activity until finish of the other
activity that resource is being used on - puts back
project completion
 moving resource from a non-critical activity
 bringing in additional resource - increases costs
Prioritizing activities
Often need to prioritize activities to resources
allocated to competing activities in a rational
order

There are two main ways of doing this:

 Total float priority – those with the smallest float
have the highest priority
 Ordered list priority – this takes account of the
duration of the activity as well as the float – see
next overhead
Burman’s priority list
Give priority to:
 Shortest critical activities
 Other critical activities
 Shortest non-critical activities
 Non-critical activities with least float
 Non-critical activities
Resource usage
 need to maximise %usage of resources i.e. reduce
idle periods between tasks
 need to balance costs against early completion
date
 need to allow for contingency
Critical path

 Scheduling resources can create new

dependencies between activities
 It is best not to add dependencies to the
activity network to reflect resource constraints
 Makes network very messy
 A resource constraint may disappear during the
project, but link remains on network
 Amend dates on schedule to reflect resource
constraints
Allocating individuals to activities

The initial ‘resource types’ for a task have to be

replaced by actual individuals.
Factors to be considered:
 Availability
 Criticality - use experienced staff for critical
jobs
 Risk
 Training – junior staff on non-critical jobs
 Team building – and motivation
Cost profile
Accumulative costs
Balancing concerns
Measuring the Triple Constraints
 Earn value management (EVM) is
 Project performance management technique
 Involves all three constraints
 Given baseline, EVM allows you to measure how
well project meets goals
 To use EVM, you need to keep project information
up to date
EVM Terms
 Planned value (PV)
 aka. budgeted cost of work scheduled (BCWS)
 is portion of total cost estimate planned to be spent on
an activity during a given period
 Actual cost (AC)
 aka. actual cost of work performed (ACWP)
 is direct and indirect costs incurred on an activity
during a given period
EVM Terms (cont’d)
 Earned value (EV),
 aka. budgeted cost of work performed (BCWP)
 is estimate of physical work actually completed
 EV is original planned costs for the project and rate that work
is completed
 Rate of performance is ratio of
 actual work completed to
 percentage of work planned to be completed
 For example, suppose the server installation was halfway
completed by the end of week 1: the rate of performance
would be 50% because by the end of week 1, the planned
schedule reflects that the task should be 100 percent
complete and only 50 percent of that work has been
completed
EVM Formulas
Key EVM Concepts
 Negative numbers for cost and schedule variance
indicate problems in those areas
 A CPI or SPI that is less than 100 % indicates
problems
 Means the project is
 costing more than planned (over budget)
 taking longer than planned (behind schedule)
Key EVM Concepts (cont’d)

If the EV line
is below the
AC or PV line,
there are
problems in
those areas.
EVM Example
 Project: 400 meters fence.
 Objectives
 To build a fence surrounding Sponsor’s & PM’s garden
 The scope consists of 4 legs each 100 meters long. Gates are included.
 Resources
 Contract signed with Contractor with fixed material price & installation
incl. necessary civil work at cost plus.
 Contractor have planned the work with a workforce of five skilled labor
working fulltime for 4 consecutive weeks
 Budget
 Material: $10,000
 Installation: $16,000 (800 man hours at $20/hour normal working
hours)
 Total: $26,000
 Schedule
 The work to be completed within 4 weeks. Lasted delivery is Friday
week 4.
EVM Example (2)
Explain:

 Material: $10,000 for 400 m

Þ $25/m for material

 Installation: $16,000
Þ $20/hour normal working hours

 Total: $26,000
=> $65/m for earned value

52
 EVM Example (3)
 Status: leg 1 of the fence is 100% completed (100 meters)
Week 1
 Task: fill in appropriate numbers in the column for wk1:
Budget:
BAC (B. at complete) 26 000
PV BAC*planned % complete 26k * 25% = 6500

Actual:
AC 100*25 + 5*8*5*20 6 500
EV BAC * actual % complete 26k * 25% = 6500
CPI EV/AC 1
SPI EV/PV 1

Forecast:

EAC BAC/CPI
53
 EVM Example (4) Week 2
 Status: leg 2 of the fence is 50% completed (50 meters)
 Reason: the soil was harder than expected, no soil investigation took place before
contract was signed
 Task: fill in appropriate numbers in the column for wk2, suggest corrective action to get
the project back on track
Budget:
BAC 26 000
PV BAC*planned % complete 26k * 50% = 13 000

Actual:
AC 6500+50*25+5*8*5*20 11 750

EV BAC*actual % complete 26k * (25 + 12.5)% = 9750

CPI EV/AC .83
SPI EV/PV .75

Forecast:
EAC BAC/CPI
54
 EVM Example (6) Week 3
 Status: leg 2 is completed/ Leg 3 is 25% completed (75 meters)
 Previous corrective action: overtime 2 hours/day for the whole workforce at a cost of $30 per
man-hour
 Task: fill in appropriate numbers in the column for wk3, and suggest corrective action to get
project back on track
Budget:
BAC
PV BAC*planned % complete

Actual:
AC
EV BAC*actual % complete

CPI EV/AC
SPI EV/PV
Forecast:

EAC BAC/CPI

55
 EVM Example (7)
Week 3
Budget:
BAC 26 000 26 000
PV 13 000 + 26 000 * 25% 19 500

Actual:

AC 11750+75*25+5*8*5*20+ 19125
5*2*5*30
EV 9750+75*65 14625
CPI 0.76
SPI 0.75

Forecast:
EAC 26 000/0.76 34211

56
 EVM Example (8) Week 4
 Status: leg 3 and 4 completed (175 meters)
 Previous corrective actions: 2 additional men, overtime 2 hours/day for the whole
workforce
 Task: fill in appropriate numbers in the column for wk4:
Budget:
BAC
PV BAC*planned % complete

Actual:
AC
EV BAC*actual % complete

CPI EV/AC
SPI EV/PV

Forecast:
EAC BAC/CPI

57
 EVM Example (9)
Week 4
Budget:
BAC 26 000
PV 26 000

Actual:
AC 19125+175*25+7*8*5*20 31200
+7*2*5*30
EV 14625+175*65 26000
CPI 0.83
SPI 1

Forecast:
EAC 31200

58
Project Portfolio Management
 Many organizations collect and control an entire
suite of projects or investments as one set of
interrelated activities in a portfolio
 Five levels for project portfolio management
1. Put all your projects in one database
2. Prioritize the projects in your database
3. Divide your projects into two or three budgets based on
type of investment
4. Automate the repository
5. Apply modern portfolio theory, including risk-return
tools that map project risk on a curve

59
Benefits of Portfolio Management
 Schlumberger saved $3 million in one year by
organizing 120 information technology projects into a
portfolio
 ROI of implementing portfolio management software
by IT departments:
 Savings of 6.5 percent of the average annual IT budget by
the end of year one
 Improved annual average project timeliness by 45.2 percent
 Reduced IT management time spent on project status
reporting by 43 percent and IT labor capitalization reporting
by 55 percent
 Decreased the time to achieve financial sign-off for new IT
projects by 20.4 percent, or 8.4 days
60
Best Practice
 A global survey released by Borland Software in 2006 suggests
that many organizations are still at a low level of maturity in
terms of how they define project goals, allocate resources, and
measure overall success of their information technology
portfolios; some of the findings include the following:
 Only 22 percent of survey respondents reported that their organization
either effectively or very effectively uses a project plan for managing
projects
 Only 17 percent have either rigorous or very rigorous processes for
project plans, which include developing a baseline and estimating
schedule, cost, and business impact of projects
 Only 20 percent agreed their organizations monitor portfolio progress
and coordinate across inter-dependent projects

61
Using Software to Assist in Cost Management

 Spreadsheets are a common tool for resource

planning, cost estimating, cost budgeting, and
cost control
 Many companies use more sophisticated and
centralized financial applications software for cost
information
 Project management software has many cost-
related features, especially enterprise PM
software
 Portfolio management software can help reduce
costs
62
Summary
 Cost management is a 3 part process
 Estimating
 Budgeting
 Controlling
 Read accompanying textbook slides