This document discusses estimating IT projects. It begins by defining estimation and explaining why IT project estimation can be difficult due to uncertainties. It then covers estimating methodologies like functional size measurement and function point analysis to objectively measure a project's size based on elements like user stories, interfaces, and data movements. The document stresses that the only certainty in projects is uncertainty and discusses techniques for translating a project's estimated size into an effort estimate while managing risks and changes. The goal is to provide reliable cost and schedule estimates for IT projects.

1. Estimating IT projects
Frank Vogelezang
Manager Pricing Office

2. 2 Agenda
Estimating IT projects
 What is estimating
 How good is your estimate
 The only certainty is uncertainty
 Cost drivers for IT projects
 Reliable estimation

3. 3 Who is
@Frank Vogelezang
Ordina
- System Integrator
- Netherlands, Belgium, Luxemburg
- close to 3,000 employees
- Manager Pricing Office
www.ordina.com
COSMIC
- Functional Size Measurement
- 23 countries
- Open Source
- President & Measurement Practices
www.cosmicon.com
Nesma
- Software Metrics Association
- Based in the Netherlands
- About 80 member organisations
- Counting Practices Committee
www.nesma.org
IWSM
- International Conference
- In 7 countries since 1991
- Academics and Industry
- Conference Chair 2014
www.iwsm-mensura.org

4. What is estimating
And why is estimating IT projects so difficult

5. IT has a bad track-record in project estimating
What is estimating
5
For a critical analysis of the Chaos reports see: www.cs.vu.nl/~x/chaos

6. IT has a bad track-record in project estimating
What is estimating
Any idea where this bad track-record comes from?
 No clear project objective
 Start with an inadequate budget
 Too little time and/or resources
 No use of benchmarking
 No idea what an estimate is
6
We can double
the estimate . . . . but then it will
ultimately be four
times as expensive!
on estimating

7. Definition of an estimate
What is estimation
How would you define an estimate?
An estimate is
 an analytical and unbiased prediction
 of how long it takes
 and what it will cost
The bias comes from the interplay with targets, commitments and plans
7

8. Target, estimate, commitment and plan
What is estimation
 Target
 Desirable business objective
 When and what
 Estimate
 Analytical prediction
 With an uncertainty range
 How and what
 Commitment
 Promise to deliver
 Defined functionality and quality
 What and when
 Plan
 Bridging the gap between estimate and commitment and mitigating the risk involved
 When and how
8

9. A typical estimate
What is estimation
9
Probability
Schedule / Cost
First likely option
50/50 median result

10. A good estimate
What is estimation
A good estimate is
 a prediction
 that provides a clear enough view
 of the project reality
 to allow the project leadership to make informed decisions
 about how to control the project
 to hit its targets.
Know where you come from, where you are and where you are going
10
Software Estimation: Demystifying the black art: www.SteveMcConnell.com

11. How good is your estimate
A simple quiz with unexpected questions

12. A simple quiz
How good is your estimate
The rules
 You get 10 questions, about anything but IT
 Answer each question with an upper and a lower boundary
 The answer should be within these bounds with a 90% chance
The objective
 To finish the quiz with 90% correct answers
 So 9 answers to the questions are within the boundaries
12

13. A simple quiz
How good is your estimate
13
1. What is the surface temperature of the sun in ºC
2. What was the total throughput of the Port of Rotterdam in 2012 in metric tons
3. World-wide box office receipts of the Lord of the Rings trilogy in US$
4. What is the total area of the Asian continent in km2
5. What is the year of birth of Alexander the Great according to Christian calender
6. The number of book titles in the Library of the Congress since 1776 in millions
7. How heavy was the heaviest blue whale ever recorded in metric tons
8. How many Euro bills were in circulation at the end of 2009 in billions
9. What is the highest point in the kingdom of the Netherlands in m
10.What is the total length of the coastline of the Pacific Ocean in km

14. A simple quiz
How good is your estimate
1. Surface temperature of the sun 6,000 ºC
2. Throughput of the Port of Rotterdam in 2012 441 million ton
3. Box office receipts of the Lord of the Rings trilogy 2.91 billion US$
4. Area of the Asian continent 44.4 million km2
5. Year of birth of Alexander the Great 356 BC
6. Book titles in the Library of the Congress since 1776 22 million
7. The heaviest blue whale ever recorded 190 ton
8. Euro bills in circulation at the end of 2009 13.6 billions
9. Highest point in the Netherlands (Mt Scenery on Saba) 877 m
10.Coastline of the Pacific Ocean 135,663 km
14

15. Estimating psychology
How good is your estimate
How well did you do this quiz?
 The average score is around 3, in line with the CHAOS reports
 We are conditioned to believe that narrow ranges are more accurate
 We feel that wide ranges make us appear ignorant or incompetent
 In real projects estimates are often biased by knowledge about the targets
15

16. Beating the estimating psychology
How good is your estimate
 If the objective is unclear, the answer cannot be precise
 IT suppliers want to do customers a favour by promising they can deliver,
although they have no idea whether it is realistic. Is that a favour?
 There are no bad suppliers, but enough substandard customers*
16
* Joep Bröcker (KPN) : www.sogeti.nl/evenementen/2010/succesvol-aanbesteden-van-ict

17. Basis of Estimate
New recommended practice standard by AACEi and
General aspects
Basis
Risk
Mitigation
17
RECOMMENDED PRACTICE
Estimation
purpose
Engagement
Scope
Description
Estimating
methodology
(FP, expert,
etc.)
Estimate
Classification
(1,2,3,4,5)
Design Basis
(Components
lists, units, etc.)
Sizing Basis
Requirements
Functional
technical
Effort Basis
delivery
constraints,
service levels
Planning Basis
Working time
standby
Level of detail
Stage, Deal
size/type, fixed
price/TM
Cost Basis
methods and
sources , units
Assumptions
internal,
external
Allowances
Not in the Basis
Exclusions
No costs
included for…
Exceptions
anomalies or
variances on
standard
Risks and
Opportunities
assumptions
Containments
cost elements
for mitigation
Contingencies
Uncertainty,
unforeseeable
elements
Management
Reserve
changes in
scope, effort
Reconciliation
Changes to
previous
estimation
Benchmarking
Comparisons to
similar
engagements
Estimate
Quality
Assurance
Reviews
Attachments Attachments Attachments Attachments

18. Coffee break

19. 19 Agenda
Estimating IT projects
 What is estimating
 How good is your estimate
 The only certainty is uncertainty
 Cost drivers for IT projects
 Reliable estimation

20. The only certainty is uncertainty
Most IT projects deliver something else than initially intended

21. Managing the devil’s triangle
Balancing between cost, time and scope
Cost
21
Time
Scope
Risk

22. Managing the devil’s triangle
Balancing between cost and time for a given size
22
Paul Masson’s
Law
Parkinson’s
Law
Brooks’
Law
Minimal time
Optimal effort
Time
Effort / Cost
Realistic
Productivity

23. The devil is in change
Traditional fixed price, fixed date projects
Cost
23
Time
Scope
Risk
Risk
Risk

24. Doubt
Let’s make room for change
The uncertainty in agile projects
Cost
24
Time
Scope
Risk

25. Cost drivers for IT projects
Sizing and estimating

26. Estimating IT projects
Two essential routes
26
Objective
Size
Effort
Cost

27. 27 Effort estimation
Estimating IT projects
 Sizing by analogy
Have we done something similar before?

28. 28 Effort estimation
Estimating IT projects
 Ask the experts to estimate using Delphi techniques
 Original Delphi:
Individual estimates | Distributed by a facilitator | Several rounds
 Wideband Delphi:
Group discussion | Individual estimates | Consensus on large variation
 Delphi – PERT:
Use Delphi to establish lower bound, higher bound and most likely value
Calculate the estimate by the formula (Lo + 4 * ML + Hi) / 6
 Planning Poker:
Estimate effort to produce a work item, related to a standard work item
Use cards with a Fibonacci (like) scale to reflect uncertainty for larger items

29. Estimating IT projects
The second route
29
Objective
Size
Estimating &
Benchmarking
Effort
Cost

30. 30 Size estimation
Estimating IT projects
 Sizing by proxy
Define repeatable elements
 Experience data per proxy element
 Technical elements: Lines of Code
Programs / Modules
Screens
Data files / Views
Interfaces
 Logical elements: User Stories / Use Cases
Processes in the Data Flow Diagram
Functional Size Measurement

31. 32 Size estimation
Functional Size Measurement – COSMIC
eXit
Write
Entry
eXit
Read
Read
Transaction oriented

32. Size estimation
Functional Size Measurement – COSMIC
Counting COSMIC function points
 Establish Functional Processes
 Determine the data movements
 # Entries
 # Writes
 # Reads
 # eXits
 Each data movement is scored
Entry 1 CFP
Write 1 CFP
Read 1 CFP
eXit 1 CFP
 A data movement can be identified alone
33

33. 34 Size estimation
Functional Size Measurement – Function Point Analysis
 FPA stands for Function
Point
Analysis
 What the software should be able to do (functionality) Function
expressed in a number Point
based on an objectively described method Analysis
 Something intangible like functionality becomes a physical number that can
be used for calculations

34. 35 Size estimation
Functional Size Measurement – Function Point Analysis
External Input
External Output
External Inquiry
Internal logical files
External input files
Data oriented

35. Size estimation
Functional Size Measurement – Function Point Analysis
Counting function points
 Based on established criteria each element is
classified:
 Each classification has its own scores
Internal files 7 10 15
External interfaces 5 7 10
External input 3 4 6
External output 4 5 7
External inquiry 3 4 6
 A function point never travels alone
36
Simple
Complex

36. Reliable estimation
Translating size into effort

37. Estimating IT projects
Translating size into effort
38
Size
Effort
Cost
Objective

38. 39 Translating size into effort
Project size as a cost driver
Size Early On time Late Failed
10 FP 11% 81% 6% 2%
100 FP 6% 75% 12% 7%
1.000 FP 1% 61% 18% 20%
10.000 FP <1% 28% 24% 48%
100.000 FP - 14% 21% 65%
Capers Jones : Applied Software Measurement

39. 40 Translating size into effort
Team size as a cost driver
MORE PEOPLE MAKE MORE NOISE

40. Translating size into effort
Team size as a cost driver
41
Paul Masson’s
Law
Parkinson’s
Law
Brooks’
Law
Minimal time
Optimal effort
Time
Effort / Cost
Realistic
Productivity

41. Translating size into effort
What can you do with Functional Size
42
 Translate functionality into a physical number that can be used to calculate:
 Required amount of hours / cost
 Schedule time
 Basis for a fixed price (per unit) that is still variable
 The calculation depends on the technology used (Java, eBS, . . .)
 But it is not a linear calculation!
Twice the size in function points is not twice as much hours / cost / time

42. Translating size into effort
How to manage all the relations
43

43. 44 Recap
Estimating IT projects
 What is estimating
 How good is your estimate
 The only certainty is uncertainty
 Cost drivers for IT projects
 Reliable estimation

44. frank.vogelezang@ordina.nl
45
WatKostIT.blogspot.nl
ThePriceofIT.blogspot.com
@FrankVogelezang
FrankVogelezang
www.linkedin.com/in/frankvogelezang