The document outlines the importance of accurate software project estimation, emphasizing that good estimates can improve morale and build reputations while serving as foundations for project planning. It discusses various types of projects and estimates, estimation processes, and strategies to enhance accuracy while highlighting common pitfalls such as optimism bias among developers. Overall, it aims to provide a clear understanding of estimation to aid project management and decision-making.

1. Estimation:
Dante’s 8th
circle…..

2. Johnnie Fox
Project Strategist
husband • geek
• photographer
• traveler •
motorcyclist •
kayaker •
traveler•entrepr
eneur •
Recovering Developer
Business Analyst
Certified Scrum Master
Drupal/Custom Development/IOS/C#
$500 - $1,000,000 projects
Project Strategist

3. Purpose of Estimate
Foundation for Project Planning
Sales Tool
Project Planning

4. Estimating Sucks
Good estimates increase morale
Good estimates build reputations
There is no pot of gold at the end of the rainbow unless
you put it there

5. Industry Performance
Software Estimation: Demystifying the
Black Art – Steve McConnel

6. Equal Chance?

7. Projects are unfair

8. Cone of Uncertainty
Software Estimation: Demystifying
the Black Art – Steve McConnel

9. Truism
The organization that most convincingly
underestimates the project has the highest chance
of being awarded the work.

10. Highly Structured
“High structure implies that the nature of the task defines
its outputs, the possibility of users changing their minds
about the desired outputs is practically nonexistent, and
significant change management issues are not present.”
1Harvard Business School Press (2004-02-19). Harvard
Business Essentials Managing Projects Large and Small: The
Fundamental Skills for Delivering on Budget and on Time
(Kindle Locations 220-223). Harvard Business Review Press.
Kindle Edition.

11. Types of Projects
New site
Site support
Migration Site to site
New features/existing site

12. Types of Estimates
Project Sizing
Sales Estimate
Project initiation estimate
In project estimation
Support estimates

13. Estimating Spreadsheet:

14. Goals
Re –usable
Consistent format
Able to use in SOW
Can be used by PM/SA on Project Inception
Margin Estimation

15. Concepts
Defensible
To Dev Team
To Client
To Sales Team

16. PM Definition
A good estimate is an estimate that provides a clear
enough view of the project reality to allow the project
leadership to make good decisions about how to control
the project to hit its targets..
McConnell, Steve (2009-11-30). Software Estimation:
Demystifying the Black Art: Demystifying the Black Art
(Best Practices (Microsoft)) (Kindle Locations 534-536).
OReilly Media - A. Kindle Edition.

17. Estimation Process
Strategies to improve Estimates
Price what you know
Knowing when its different?
Ask someone who has done it before
Examine prior projects

18. Caution:
In a study of 300 software projects, Michiel van
Genuchten reported that developer estimates
tended to contain an optimism factor of 20% to
30% (van Genuchten 1991).Although managers
sometimes complain otherwise, developers don’t
tend to sandbag.
theirMcConnell, Steve (2009-11-30).
Software Estimation: Demystifying the Black
Art: Demystifying the Black Art (Best
Practices (Microsoft)) (Kindle Locations
1095-1096). OReilly Media - A. Kindle
Edition

19. Promet Caution
Promet recourses tend not to estimate any related
tasks to the item they are estimating (Theme, PM,
Setup time)

20. Types of Time
Dev time
Themer Time
Project Management
Quality Assurance
DevOps/Sysadmin

21. WBS
Modified Delphi Estimation method.
Developed by Rand Corporation in the
40's
Fancy word for list - Work Breakdown
Structure (WBS)
Make estimate separate and then compare
• After lists are made members meet and compare lists.
• Everyone must participate.
• If there is no conflict and you didn't get any additions you are
doing it wrong.

22. Translating Clients
Customers want features in their list
Our job is to translate it into features the team can
complete

23. The Size of Time
Hour sizes 1, 2, 4, 8, 16,
Beyond 16 hrs
You don’t know what the task is
Easy target for “Shouldn’t this be Lower”

24. Percentage Factors
PM Time 20%
QA Time 15%

25. Minimum Cost
Dev Ops 4 – 12 hours
Training
Kickoff meetings

26. Standard Blocks
Sprint 0
Design
Core Drupal (list)
Contrib modules (list)
SEO modules
Social Sharing
Custom features
• Workflow
• Integrations
• Ecommerce
• 3rd
party
• Themeing
• Desktop
• Responsive

27. Standard Blocks
Integration
AMS (CIVI etc)
SSO
Billing/ecommerce
Training
Dev Ops
Project Management
QA

28. Next Steps
Re-use Estimates
Stock assemblies?
Factors of Scale/size
Granularity
Sales use only tool
Estimation among other PMs
Real world feedback

29. Risks
Missed requirements
Technical Debt
Incorrect assumptions
Infrastructure (VPN, Server Access)
Poor client conditions
Uninvolved/Unresponsive
Contact not technically savvy

30. Effort per Estimate

31. Project Size

32. Johnnie Fox
Johnnie@promethost.com
twitter: johnniefox