allaboutxpert.com cape town t: +27 21 510 8655 / 552 0143 f: +27 21 510 8940 / 086 682 4035...
TRANSCRIPT
allaboutxpert.com
Cape Town t: +27 21 510 8655 / 552 0143 f: +27 21 510 8940 / 086 682 4035 Johannesburg t: +27 11 549 8600 f: +27 11 549 8635Client support: 0860 aboutp (22 68 87)Email: [email protected] © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltdDirectors: Dee Alho, Ayob Alli, Dana Brennan, Ada de Wet, Dennis Grant, Mark Jurgens (Non-Executive), Graham Moore, Matthew Pitman, Nic WaltersRegistration Number:
1995/012254/07
Estimation
SPR Introduction
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
Building a Business Case for Estimation
2
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
“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.
Overruns
0.00%
10.00%
20.00%
30.00%
40.00%
Under
20%
21 - 50% 51 - 100% 101 -
200%
201 -
400%
Over
400%
Cost
Time
Features and Functionality
5%
27%
22%
39%
7%Less Than 25%
25 - 49%
50 - 74%
75 - 99%
100%
0%
10%
20%
30%
40%
50%
60%
Year 1994 1996 1998 2000 2002
Suceeded
Failed
Challenged
The above findings have been consistent for the last 25 years
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
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.
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
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
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
Generic Problem Statement - DetailPeople•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
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
SPR KnowledgePlan
SPR KnowledgePLAN®
Formal Software Project Estimation
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
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.
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
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.
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
SPR Knowledge Base
Project Size
Project Classification
Project TypeLarge 23%
Medium 50%
Small 27%
Enhancement 48%
New 31%
Maintenance 21%
Systems 30%
IT 45%
Other 16%
Commercial 10%
14,531 projects in Version 4.3 (2009)
10
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
SPR KnowledgePLAN - Overview
WBSSoftware Project Types
Environmental AttributesSizing Methods
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
Key stages to EstimationHow does KnowledgePLAN support a 4 stage estimation
process
Sizing Complexity Capability Process
How big? How difficult?
Mitigatedby tools andlanguages
How capable?
RISK mustbe
properlyassessed
Which tasks?
Waterfall
AgileRUPIterative-Spiral
DSDM
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
SPR Sizing
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
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 MetricsSizing 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 14000 projects in the Knowledge Base
Sizing Complexity Capability Process
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
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
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
Estimation Stage - Capability
Sizing Complexity Capability Process
TechnoloTechnologygy
ProcessProcess
EnvironmeEnvironmentnt
Personnel
SOFTWAREQUALITY
ANDPRODUCTIVITY
ProductProduct
PersonnelPersonnelExperience and skills of: managers, developers, users
TechnologyTechnologySoftware tools and platform issues
ProcessProcessDevelopment methods, quality assurance, testing, documentation
ProductProductHardware and software requirements, constraints, and architectures
EnvironmentEnvironmentOrganization, office and physical environment
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
Estimation Stage- Process
Tasks are selected by the model and may be adjusted
TASK CATEGORYTask 1Task 2Task 3
TASK CATEGORYTask 1Task 2Task 3Task 4
TASK CATEGORYTask 1Task 2
TASK CATEGORYTask 1Task 2Task 3 Requirements
DesignsCodeTest casesDocumentation
• 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
Sizing Complexity Capability Process
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
Reporting
17
Detailed reporting allows for easy interrogation of data
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
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).
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
Estimation - Processes
19
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
When do we estimate in the Innovation lifecycle & why?
High Level Design Detailed Design Build, Test, Fix Implementation
E
Stage In Process:Middle of Detailed Design (DD) which implies - no later than 6 weeks into Detail Design / End of Detail Design
Reason for EstimationFor 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 E
Stage In Process:End of High Level Design
Stage In Process:Release into Production
Idea Cloud / Concept Evaluation
Estimation by Analogy to assist withPre-Execution Budget .
Stage In Process:Beginning of the idea/concept phase.
EOptional Mandatory
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
What are the key inputs & documents?
High Level Design Detailed Design Build, Test, Fix Implementation
E E E
Idea Cloud / Concept Evaluation
HL Business Requirements
HL Architectural Design
Component Model
Process Definition
Architectural Design
Functional Specification
TechnicalSpecification
Updated Documents
Component count
(avg complexity
)
Analogy Estimate Produced
Function point count (detailed
complexity)
Tracked project
Actuals vs Est.Estimation
& Estimation
report created
New Idea Logged
ApprovedBusiness
case
Business RequirementsSpecification n
Project Close-
out
Estimation EAQ
Estimation EAQ
Estimation EAQ
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
What technique do we use for estimation?
High Level Design Detailed Design Build, Test, Fix Implementation
E
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
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
E E
Idea Cloud / Concept
Evaluation
Stage In Process:Beginning of the concept phase
Technique - Analogy•Optionally–using to size and estimate projects where very littlie information is available.
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
What are our confidence factors for estimation in the different phases of the lifecycle?
High Level Design Detailed Design Build, Test, Fix Implementation
E
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
E E
Estimation Confidence Factor50 – 60%
Estimation Confidence FactorMiddle of Detailed Design = 60%End of Detailed Design = 85%
Estimation Confidence FactorActual = 100%
Idea Cloud / Concept
Evaluation
E
Estimation Confidence Factor20-40 %
Stage In Process: Beginning of the Concept Phase
PLA
YP
EN
(E
xist
ing
Pro
cess
app
ly)
copyright © 2011: all content is the copyright of X-Pert Group (pty) ltd and/or allabout projectmanagement (pty) ltd
Estimation confidence
20%
CONFIDENCE
40%
60%
85%
ANALOGY METRIC(COMPONENT)
METRIC
Detailed Design Build, Test, Fix ImplementationHigh LevelDesign
Idea Cloud/ Concept Evaluation