1. Estimation
SPR Introduction

2. Building a Business Case for Estimation

3. “Staggering Stats” The Standish Group “Chaos” report shows:
31.1% of projects will be cancelled before they ever get completed.
52.7% of projects will cost 189% of their original estimates.
The cost of these failures and overruns are just the tip of the iceberg. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars.
Only 16.2% for software projects that are completed on-time and on-budget. .
Even when these projects are completed, many are no more than a mere shadow of their original specification requirements.
Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions.
The above findings have been consistent for the last 25 years

4. Estimation Why do we need to estimate?
To work out how much effort & cost might be involved to deliver a project often based on incomplete input data that may be incomplete or uncertain.
To plan
To run through scenarios to determine feasibility
Why is estimation of software projects difficult?
Types of Estimation technique may be based on developer opinion, apply Methods like function block counting or broadband delphi or use Rules of Thumb - all are mostly based on guesswork, personality and resource experience, can be time consuming and are often inconsistently applied.
“Accurate software estimating is too difficult for simple rules of thumb.”
~ Capers Jones, 1991
How do we introduce more accurate estimation?
Through the introduction of a method to determine the size of the functionality (function point analysis) to be delivered by a software project and using this as a base from which effort to deliver functionality can be estimated.
This can allow for a more scientific approach and consistently applied process to estimating effort and cost.

5. Generic Problem Statement (Summary)
There is no standard estimation process
Project managers make use of their own tools, methods and processes to come up with estimates. These are therefore inconsistent and often dependant on the experience and knowledge of the Project Manager
There is no central repository for recording estimates
Assumptions therefore cannot be traced and this problem is compounded by turnover of project management staff.
Initial estimates that drive the initial budgeting process tend to be significantly lower then final budget/actuals.
History shows the Projects planned for the release miss their release dates. This will increase costs and project delivery timelines.
A large percentage of active projects have no baseline in place.
Estimation is inconsistent and ever changing

6. Generic Problem Statement - Detail
People
Lack of clarity around who does the estimates and who is responsible for the estimates
Skills not adequate to deliver accurate estimates
Limited understanding of the estimation process and terminology
Process
Business do not understand the estimation process and their input into this process.
Lack of clearly defined scope management process and principles from an estimation perspective
Estimation is dependant on the forecasting and budgeting process, which is financially driven rather than size driven.
Systems
Lack of historical information
Lack of industry benchmarks
Lack of a central repository for storing estimations and assumptions.
Practice
Estimation process is dependant on the requirements process, which is new and slowly maturing within the many environments.
No standards exist in terms of sizing (Function Point count)
The above issues result in variances in time, cost and effort when compared to actuals

7. Formal Software Project Estimation
SPR KnowledgePlan
SPR KnowledgePLAN®
Formal Software Project Estimation

8. SPR History
Software Productivity Research (SPR) was founded in 1984 by Capers Jones, an internationally recognized consultant, speaker, author and seminar leader in the field of software management.
SPR is a worldwide provider of consulting services that enable organizations to compete more effectively through the predictable, on-time delivery of high-quality software by focusing on software estimation, measurement, and assessment. Their services help companies manage the software development process for maximum productivity, performance, and quality.
SPR’s clients include many of the Global 1000 companies, representing all major software environments including systems, IT, commercial, military, and government. They focus on capturing and analyzing the software practices of Best in Class organizations - those recognized for outstanding quality and service. In addition, they help software organizations achieve higher performance as they progress on the road to excellence.
Headquartered in Hendersonville, North Carolina, with representation throughout the US, South America, Europe, Asia and now Africa, SPR has unparalleled expertise in estimation, benchmarking, measurement, function point analysis, and process assessment. They have been providing superior products and services in these areas longer than any other company in the field today, and they use this experience effectively to enhance our clients' capabilities.

9. What is SPR KnowledgePLAN?
KnowledgePLAN is a parametric estimation tool that uses historical data about projects correlated to Function Point size to produce detailed, bottom-up (micro estimation) predictions of software projects
With SPR KnowledgePLAN you can:
Determine SIZE - size your projects using three possible sizing methods
Effort - Produce an estimate of effort, cost and resource required for a software project.
Estimate Quality - Predict the total number of defects that will be introduced during various stages of the project
Project Factors - Assess the influence of project factors such as product size and complexity, team skill sets, management style, tools, languages, methods, quality practices, and office environment
Scenario Play - SPR KnowledgePLAN allows a software project to explore the cost/value implications of additional resources, more powerful languages, development tools, improved methods and other technical changes.
- SPR allows approximation of functional size from which effort can be determined considering various of influencing project factors. Scenario play gives insight to the impact of these factors on effort and duration numbers to deliver approximated size.

10. SPR Knowledge Base Project Size Project Classification Project Type
14,531 projects in Version 4.3 (2009)
Project Size
Project Classification
Project Type
Large 23%
Medium 50%
Small 27%
Enhancement 48%
New 31%
Maintenance 21%
Systems 30%
IT 45%
Other 16%
Commercial 10%
© 2009, Software Productivity Research, LLC. Global Rights Reserved.

11. SPR KnowledgePLAN - Overview
Sizing Methods
Environmental Attributes
Software Project Types
WBS

12. Key stages to Estimation
How does KnowledgePLAN support a 4 stage estimation process
How big?
How difficult?
How capable?
Which tasks?
Sizing
Complexity
Capability
Process
Mitigated
by tools and
languages
RISK must be
properly
assessed
Waterfall
Agile
RUP
Iterative-Spiral
DSDM

13. SPR Sizing SPR support three different types of sizing methods.
Complexity
Capability
Process
Sizing by Metrics
Sizing can be input by various metrics:
Function Points (Recommended)
IFPUG/NESMA
COSMIC FFP
Mark II
Object Points
Estimated Function Points
Technical (approximation) Function Points
Logical System Lines of Code
SPR support three different types of sizing methods.
This allows organizations to align methods to specific inputs into estimation that become available through the Project Lifecycle
More than projects in the Knowledge Base
Sizing by Components
Use a multi-tiered approach to sizing
Estimate built from known values
Approximation accuracy approaches that of FPA
Combine with Size by Metric when more is known
Sizing by Analogy
Estimates can be made against a variety of software products in the table, further categorized by size (small/medium/large)
The portions of enhancement projects that are New, Enhancement, Maintenance, and Conversion effort are recorded here

14. Estimation Stage - Complexity
Complexity factors are rated for projects
Sizing
Complexity
Capability
Process
Algorithmic (“Problem”) complexity
Correction for effort within the application boundary
Structural (“Code”) complexity
Quantitative scale describes recursive statements
High complexity somewhat mitigated by high-level languages/skills
Relational (“Data”) complexity
Extent of data organization complexity
High complexity somewhat mitigated by data modeling

15. Estimation Stage - Capability
Sizing
Complexity
Capability
Process
Technology
Software tools and platform issues
Technology
Process
Environment
Personnel
SOFTWARE
QUALITY
AND
PRODUCTIVITY
Product
Process
Development methods, quality assurance, testing, documentation
Personnel
Experience and skills of: managers, developers, users
Product
Hardware and software requirements, constraints, and architectures
Environment
Organization, office and physical environment

16. Estimation Stage- Process
Sizing
Complexity
Capability
Process
Tasks are selected by the model and may be adjusted
Projects are made up of tasks for which deliverables are predicted based on historical information in each task category
134 task categories are available in the tool
TASK CATEGORY
Task 1
Task 2
Task 3
TASK CATEGORY
Task 1
Task 2
Task 3
Requirements
Designs
Code
Test cases
Documentation
TASK CATEGORY
Task 1
Task 2
Task 3
Task 4
TASK CATEGORY
Task 1
Task 2

17. Detailed reporting allows for easy interrogation of data

18. SPR Limitations
It is not a substitute for good planning (it is only a part of it)
Project managers still need to:
Discuss, agree and monitor delivery with project resources
Manage dependencies, issues and risks
Manage their project calendar and resources pool
Keep their plans updated and relevant!
The tool has its limitations and cannot estimate:
Estimate projects with no sizeable software development(SDLC) components
Estimate on peripheral constraints and impacts to project cost and duration outside of what can be captured into the Tool (i.e.: infrastructural changes, resource unavailability, Fixed/CAPEX costs, delays, freeze periods).

19. Estimation - Processes

20. When do we estimate in the Innovation lifecycle & why?
Stage In Process:
Beginning of the idea/concept phase.
Stage In Process:
Middle of Detailed Design (DD) which implies - no later than 6 weeks into Detail Design / End of Detail Design
Stage In Process:
End of High Level Design
Stage In Process:
Release into Production
Innovation Project Lifecycle
Idea Cloud /
Concept Evaluation
High Level Design
Detailed Design
Build, Test, Fix
Implementation E E E
Estimation by Analogy
to assist with
Pre-Execution Budget .
Reason for Estimation
For input around time,
cost & effort estimates
into the business case
Reason for Estimation
To review & revise the execution budget.
To provide time, cost & effort estimates.
Reason Actual vs Estimate Analysis
To understand actuals & perform variance analysis from earlier phases in order to understand route cause of variances.
To record historical data for future use by estimations of other similar projects going forward. E
Optional
Mandatory

21. What are the key inputs & documents?
Idea Cloud /
Concept Evaluation
High Level Design
Detailed Design
Build, Test, Fix
Implementation E E E
Inputs / documents
New Idea Logged
HL Business
Requirements
Business
Requirements
Specification n
Project Close-out
HL Architectural
Design
Process
Definition
Architectural
Design
Component
Model
Functional
Specification
Technical
Specification
Updated Documents
Approved
Business
case
Estimation
EAQ
Estimation
EAQ
Estimation
EAQ
Key SPR specific estimation documents required are the Estimation Environmental Assessment Questionaire
This document allows for the rating of estimation attributes (Capabilities of dev team , involvement of business, quality assurance measures etc)
It allows for dev teams to provide a view of perceived development complexity for both what is to be added as new, changed and re –added or changed as part of existing code.
Estimation
outputs
Function point count (detailed complexity)
Analogy Estimate Produced
Component count (avg complexity)
Tracked project Actuals vs Est.
Estimation & Estimation report created

22. What technique do we use for estimation?
Stage In Process:
Beginning of the concept
phase
Stage In Process:
End of High Level Design
Stage In Process:
Middle of Detailed Design / End of Detailed Design
Stage In Process:
Release into Production
Innovation Project Lifecycle
Idea Cloud /
Concept
Evaluation
High Level Design
Detailed Design
Build, Test, Fix
Implementation E E E
Technique - Analogy
Optionally–using to size and estimate projects where very littlie information is available.
Technique – Component
Compile estimation input from all areas and collate for overall time & effort.
Inputs from other Group Technology areas: High Level Work Breakdown Structure with expert based estimation
Technique – Metric (FP count)
Detailed documentation
Detailed Work Breakdown Structure
Technique Actuals versus Estimated tracking and comparison based off
Function Point Counting
Looking at actual project schedule
Capture Actual value

23. What are our confidence factors for estimation in the different phases of the lifecycle?
Stage In Process: Beginning of the Concept Phase
Stage In Process:
End of High Level Design
Stage In Process:
Middle of Detailed Design / End of Detailed Design
Stage In Process:
Release into Production
Innovation Project Lifecycle
Idea Cloud /
Concept
Evaluation
High Level Design
Detailed Design
Build, Test, Fix
Implementation
PLAYPEN (Existing Process apply) E E E E
Estimation Confidence Factor
20-40 %
Estimation Confidence Factor
50 – 60%
Estimation Confidence Factor
Middle of Detailed Design = 60%
End of Detailed Design = 85%
Estimation Confidence Factor
Actual = 100%
Confidence levels are dependent requirement & scope stability as well as the detail and accuracy of conceptual and detailed design documentation that is used as input into the estimation types.
Highest confidence levels are achieved through estimation by Metric where functional sizing is done through the application of function point analysis.
Analogy estimations can provide an accurate view however this remains a method through which functional size is approximated based on relating a projects intended functional object to very high level descriptions in the knowledgeBASE. In order for the upper end of the confidence scale to be achieved using analogy enterprise specific analogies would need to be created. In so doing the variability inherent with this type of estimation is reduced.

24. Estimation confidence
Build, Test, Fix
Implementation
Idea Cloud/ Concept
Evaluation
High Level
Design
Detailed Design
ANALOGY
METRIC
(COMPONENT)
METRIC
CONFIDENCE
85%
60%
40%
20%