1. Guest Lecture: Project Estimating Wolfgang Behr, Accenture
TU München Applied Software Engineering Prof. Bernd Brügge Software Engineering II, SS 2005
Guest Lecture: Project Estimating
Wolfgang Behr, Accenture
Copyright © 2005 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture.

2. Objectives for Today Build an understanding of…
… the importance of estimations
… different estimation approaches (initial situation, expectations, top-down versus bottom-up, …)
… advantages and disadvantages of different approaches
… common pitfalls

3. Initial Situation
Copyright © 2005 Accenture All Rights Reserved.

4. Importance of Estimations
During the planning phase of a project, a first guess about cost and time is necessary
Estimations (as part of the project business case) are therefore the basis for the decision to start a project
Estimations are the foundation for project planning (resources, staffing, project schedule) and for further actions (market entry, marketing, etc.)
à Estimating is one of the core tasks of project management !

5. Challenges Incomplete knowledge about: Project scope and changes
Prospective resources / staffing
Technical and organizational environment / infrastructure
Feasibility of functional requirements
Comparability of projects in case of new or changing technologies, staff, software engineering approaches
Learning curve problem (increasing productivity over time, especially when staffing new personnel)
Different expectations towards project manager (buyer -> low estimation; contractor -> at least “realistic” estimation…; in general: “political” estimations; tendency to be optimistic)

6. Guiding Principles Documentation of assumptions about:
Estimation methodology
Project scope, staffing, technology etc.
Definition of estimation accuracy or definition of result bandwidth
Increasing accuracy with proceeding project phases (for example: detailed estimation for implementation phase after detailed functional design)
Reviews by experienced colleagues

7. Components of a Project Estimation
Cost
Personnel (in person days * (PD) or valued in cost)
Material (PCs, software, tools etc.)
Extra costs (travel expenses, etc.)
Time
Project duration
Dependencies
Personnel (number, qualification, availability)
Infrastructure (rooms, technical infrastructure etc.; especially in offshore scenarios)
* person day = effort for one person per working day

8. Estimation Approach Determination of estimated person days
Allocation to staff types (teamlead, functional expert, programmer, etc.) either:
Single cost rate* for all types (no differentiation necessary)
Different cost rates depending on staff type (experience, skills etc.)
Personnel cost = person days x cost rate
* Cost rate = cost per person per day

9. Determination of Person Days (Effort)
Most difficult part during project planning (many other planning tasks (especially project schedule) depend on this)
Basic principles:: Evaluation of known information (about project scope, resources etc.) and conversion into effort
Most important: knowledge about project scope (what needs to be done), reuse of software engineering approach (steps, work products) and in general: lots of experience

10. Top-Down versus Bottom-Up (1)
There are two possible approaches for estimations:
Top-Down Approach Estimation for whole project; then breakdown to different project phases and work products (possibly by using percentages, for example: 10% for project management is a common number)
Bottom-Up Approach Estimation of work products on lowest possible level; then aggregation to top-level; possibly supplemented by some general percentages (see above)
à Usually, a mixed approach with recurrent estimation cycles is used !

11. Top-Down versus Bottom-Up (2)
Top-Down Approach
Normally used in the planning or project idea generation phase (little information)
Based on experiences from similar projects
Not appropriate for project controlling (too high-level)
Risk add-ons usual
Bottom-Up Approach
Rules based (in order to increase comparability)
Result can be used for project controlling (detailed level)
Smaller risk add-ons

12. Work Breakdown Structure
Hierarchy of all project work products and tasks which are necessary to reach the project result
Structured description of all relevant project tasks (but always based on results / work products !)
Decomposition of tasks used to assign responsibilities
Basis for estimation, budgeting, staffing and controlling
Historically oriented on end product (system and its parts), now increasingly oriented on tasks and processes

13. Example: WBS

14. Estimation Approaches
There are different approaches available to do project estimations:
Expert estimations (“Expertenschätzungen”) and analogies (top-down)
Lines of code estimations
Function point analysis (top-down)
COCOMO
Alternative Approach

15. Expert Estimations
Copyright © 2005 Accenture All Rights Reserved.

16. Expert Estimations = Guess from experienced people
No better than the participants
Suitable for atypical projects
Result justification difficult
Important when no detailed estimation can be done (due to lacking information about scope etc.)

17. Function Point Analysis
Copyright © 2005 Accenture All Rights Reserved.

18. Function Point Analysis
Initially developed by Albrecht, A.J., IBM Research, 1979
Method for determining dimension and complexity of software projects, depending on the system functions (not on tasks !)
Estimations are based on a user view (functionality)
Independent of…
Implementation language / technology
Software engineering approach
Top-Down approach

19. Function Types # of external input (Eingabefunktionen, EF)
# of external output (Berechnungsfunktionen, BF)
# of external inquiries (Abfragefunktionen, AF)
# of logical internal files (Dateneinheiten, DE)
# of external interface files (Schnittstellen zu externen Systemen, SES)
Result: unadjusted function points:
UFP = (a · EF) + (b · BF) + (c · AF) + (d · DE) + (e · SES)
a-f = weight factors (see following slide)

20. Determining Unadjusted Function Points
Weight Factors
Function Type
Number
simple
middle
complex
Input Functions x 3 4 6 =
Calculation Functions x 4 5 7 =
Query Functions x 3 4 6 =
Datasets x 7 10 15 =
Interfaces x 5 7 10 =
# Unadjusted Function Points =

21. Adjusting Function Points
Function points are then adjusted depending on system complexity, represented by 14 general complexity factors (for example transaction rate, performance, online data input, …), valid for the whole system
Weighted complexity numbers between 0 (not important) to 5 (very important)
Result: System Complexity Factor (SCF):
SCF = 0,65 + (0,01 · Sum of weight factors)
(Thus, the results can vary by 35% due to the general system complexity factors…)
Then: Calculation of Function Points (FP):
FP = UFP · SCF

22. Advantages of Function Point Analysis
Independent of implementation language and technology (no LOC (lines of code) determination necessary)
Estimates are based on design specification (results, which are usually known before necessary tasks are known)
Users without technical knowledge can be integrated into the estimation process -> increases acceptance of estimation
Incorporation of experiences from different organizations (but resulting also different factors)
Adaptable to new technologies and individual situations
Easy to learn and limited time effort

23. Disadvantages of Function Point Analysis
Complexity of the function (the result) is estimated – but: complexity of its implementation would be the relevant factor for an estimation !
Complete description of functions necessary (often not the case in early project stages) -> too much focus on functionality
High uncertainty in calculating function points:
Components difficult to determine
Weight factors deducted from past experiences (independency from technology ?)
Difficulty to determine weight factors
Increasing uncertainty in case of emphasis on a certain type of function types (for example output functions)
Code reuse and external providers of software components are not considered
Task planning and controlling not possible (also: no breakdown to single project phases considered)

24. Conclusion
Good as a support tool for determining functionality of a system
Involvement of persons without deep technical understanding increases acceptance – but: they have to be trained in using the method
High uncertainties
Further developments (see IFPUG, International Function Point Users Group)
Feature Points (better, if emphasis on special function types; it considers also algorithm complexity)

25. COCOMO
Copyright © 2005 Accenture All Rights Reserved.

26. COnstructive COst MOdel (COCOMO)
Developed by Boehm, Barry W., “Software Engineering Economics”, Prentice-Hall, 1981
Top-down approach to estimate cost, effort and schedule of software projects, based on size and complexity of projects
Assumptions:
Derivability of effort by comparing finished projects (COCOMO database)
System requirements do not change during development
Exclusion of some efforts (for example admin, training, rollout, integration, etc.)

27. Approach
Estimation of number of instructions (“Kilo Delivered Source Instructions” = KDSI)
Determination of project complexity by scale factors
simple project (“organic mode”)
Semi-complex project (“semidetached mode”)
complex project (“embedded mode”)
Other cost factors are rated on a qualitative scale between “very low” and “extra high” and multiplied whith each other; by using them, more accurate estimations are possible
Software reliability
Data base size
Programmer capability
etc.
einfach: kleine Entwicklergruppen arbeiten in bekanntem Problemumfeld
mittelschwer: Komplexität zwischen „einfach“ und „komplex“
kompex: komplexes, im Wesentlichen unbekanntes Problemumfeld
[PM] bedeutet „Einheit in Personenmonaten“
[KDSI] bedeutet „Einheit ist Kilo Delivered Source Instructions“

28. Calculation of Effort Basic formula: A = C * KLOCB
A = Effort in man months
B, C = constants
Project C B
Simple 2,4 1,05
Semi-Complex 3,0 1,12
Complex 3,6 1,20
einfach: kleine Entwicklergruppen arbeiten in bekanntem Problemumfeld
mittelschwer: Komplexität zwischen „einfach“ und „komplex“
kompex: komplexes, im Wesentlichen unbekanntes Problemumfeld
[PM] bedeutet „Einheit in Personenmonaten“
[KDSI] bedeutet „Einheit ist Kilo Delivered Source Instructions“

29. Calculation of Time to Develop
Basic formula:
T = D * AE
T = Time to develop
D, E = constants
A = Effort in man months (see slide before)
Project D E
Simple 2,5 0,38
Semi-Complex 2,5 0,35
Complex 2,5 0,32
einfach: kleine Entwicklergruppen arbeiten in bekanntem Problemumfeld
mittelschwer: Komplexität zwischen „einfach“ und „komplex“
kompex: komplexes, im Wesentlichen unbekanntes Problemumfeld
[PM] bedeutet „Einheit in Personenmonaten“
[KDSI] bedeutet „Einheit ist Kilo Delivered Source Instructions“

30. Advantages of COCOMO
Appropriate for a quick, high-level estimation of project costs
Fair results with smaller projects which are done in a known development environment (comparison with past projects is possible)
All project phases (from design to test) are covered (partially by using experiences like 10% project management, 10% infrastructure etc.)

31. Disadvantages of COCOMO
Some very important factors are not considered in the original model:
Development hardware
Use of modern CASE tools
Skills of team members
Management quality
User interface quality
Comparability with past projects not always possible
Lots of influencing factors which have to be determined in advance

32. Conclusion Use it for quick estimations after first analysis phase
Results will improve if one large project is split up into smaller part projects which are estimated separately
Experience shows, that estimation results can deviate from real effort by a factor of 4 !
There are further developments in place:
COCOMO II (since the mid 1990s) and others
Commercial versions

33. Alternative Model
Copyright © 2005 Accenture All Rights Reserved.

34. Approach (1) Use both top-down and bottom-up elements:
Determine essential characteristics of a project (infrastructure, technology, project team skills and experience, etc.) and derive some generic factors
Factors for fixed efforts and activities like 10% for project management or infrastructure
Factors for project phases (for example 50% test effort), often derived from already finished phases (step-by-step detailling of estimations)

35. Approach (2)
Determine all work products (WBS…) of the system to be developed (# of screens, # of database tables, # of queries, # of logical modules etc.) and give them complexity factors
Determine work product types (screen, table, module, …)
Define all necessary tasks that need to be done to produce these work product types (for example design, coding, unit test are tasks to produce a module)
Assign effort to tasks by using past experience
Extrapolate to project effort (summing up)
Use add-ons (contingency and risk factors)

36. Example (non-exhaustive)
Work Package
Complexity
Type
Multiplier / Factor
PDs
Requirements Elicitation 29
Function A
Low
Use Case 1 5
Function B
Medium 8
Function C 2 16
Etc.
Implementation 39
Screen A
High
Screen 18
Screen B
Batch Job A
Batch
Batch Job B
Technical Architecture
10 %
3,9
10% of

37. Prerequisites
Identical estimation approach for different projects necessary
Lots of experience with estimating projects necessary in order to develop good parameters
Multicheck of top-down with bottom-up results and vice versa
Post calculation after end of project important for improving parameters

38. Summary and Outlook Project Estimating
Copyright © 2005 Accenture All Rights Reserved.

39. Importance of Estimations (1)
Basis for decision to start, plan and manage a project (project controlling, earned-value analysis)
If used properly, transparent way to discuss project scope and effort
All approaches depend very much on personal experiences
Approaches have lots of possibilities to influence the results (“Stellschrauben”) – these have to be used carefully

40. Importance of Estimations (2)
Estimation results (effort and time) are almost always too high (for political / human reasons) and have to be adjusted in a structured and careful manner
Review by experts (top-down versus bottom-up) are always necessary
New technologies can make new parameters necessary
Depending on the situation, multiple methods are to be used in combination

41. Outlook Project Planning
In general, Duration = Effort / People, but:
A larger project team increases team communication complexity which usually reduces productivity
Therefore it is not possible to reduce duration ad libitum by adding more people to a project (on the contrary, it can even take longer !)
A trade-off has always to be found between duration and people

42. Questions ?