1. Project estimation Biased advice on producing accurate project estimates and managing expectations with stakeholders. Morgan Strong

2. What are we doing today?  Art vs Science. I know nothing of the science. Hopefully we can help with art.  Estimates vs. Commitments vs. Targets.  Estimation concepts.  Collecting relevant data to help current and future projects.  Some estimation techniques.

3. What is an estimate?  Prediction of how long or expensive to will be finish a project.  But, management / clients / sponsors will use targets and commitments interchangeably.  The first, most important component is understanding what is actually driving a project and building your estimates around commitments and targets.

4. Targets and Commitments  Targets are desirable business outcomes.  “The website needs to be updated for new financial rules”  “The apps needs to be shipped ready for school holidays”  Commitments are promises to deliver something to a particular level at a specific date.  Commitments may be the same as a target…  Or it may more or less conservative.

5. Estimates and planning  These are actually different things.  Estimates should unbiased, analytical exercises in understanding how long / expensive a project will be.  Plans are goal-seeking processes – biasing the progress of a project to achieve a particular outcome.  Presenting a plan as an estimate gives it objectivity it doesn’t deserve.  Estimates should inform plans and where there is a substantial difference between the targets and estimates, the plan has appropriate levels of risk management.

6. What’s an estimate then?  What’s a bad estimate?  One subject to miscommunication. Targets and estimates are used interchangeably and become the point at which you cannot argue that something is not possible. Worst still, this minimum possibility becomes a business commitment.  What’s a good estimate?  A good estimate provides a realistic view of a project reality so controls can enable the project to hit its targets.

7. Concepts - confidence  Understanding ranges – 90% confidence is implied with estimates (most projects have +/-5% tolerance). But what does 90% confidence look like?  Give a range for the volume of coal exported from Queensland in 2014 with 90% confidence.  216,000,000 tons.  We naturally like to give narrower range as that seems more authoritative.

8. Concepts - confidence  Software / web / IT – notorious for under-estimating projects.  There’s not really an issue that we under-estimating 50% of the time and over-estimating 50%.  How do we become more confident?  Communicate – estimates vs commitments.  Basic project planning and controls (in particular dependencies from the above miscommunications).  But, more importantly, we need data to be more confident.

9. Concepts - uncertainty  There are periods where we are less certain of where a project is heading – usually at the start.  Other influences on uncertainty: type of project; personnel / skill level; diseconomies of scale; platform and module choice.  More adjustments points, more chance for subjective decisions to affect estimation accuracy.  The biggest influences: project uncertainty and lack of comparative data.

10. Concepts - influencers  Old school, but still useful – Cocomo II model helps give you an idea of adjustments that should made to estimates from data (number is variability in estimation / divided by significance). Complexity2.38Documentation required1.52Database size1.42 Requirements analyst2.00Applications experience1.51Platform experience1.40 Programmer capability1.76Software tools1.50Architecture and risk1.38 Time constraint1.63Platform volatility1.49Precedentedness1.33 Turnover1.59Storage constraint1.46Developed for reuse1.31 Multisite development1.56Process maturity1.43Team Cohesion1.29 Required reliability1.54Language experience1.43Dev flexibility1.26

11. Collecting data  Previous performance is an excellent indicator.  Industry data worst; company data good; project data best.  Tendency to be optimistic about efficiency gains and ability to learn from previous mistakes.  Acknowledge where there are improvement gains in platform – e.g. chef or puppet will change sysadmin; drush vs ftp etc.  Start collecting data during the project.

12. Collecting data  What’s useful?  Story points / use cases / tasks  Staff effort / hours / hours over time  Bugs / user testing / audits  Modules / module dependency / interoperability  Resolution time / requirements resolution / refinement etc.  Be consistent!  Same bug reported in different ways  Where a project starts and ends (harder than it sounds)

13. Here’s three common techniques  Count, compute, judge  Count first (something that’s correlated to the size); then compute when you can’t count (historic data that allows proxy); judge when only when you must.  Calibrate against historic data  Where possible, use relevant project data to inform: productivity assumptions; organisational style; consistency in measuring etc.  Start collecting data as project progresses – calibrating current project against historic records creates very accurate correlations for the rest of the project.  Expert judgment  Good for when there’s large unknowns – bring in the best experts opinion you can for all components. Group reviews do help remove personal bias – be careful to minimise subjective optimism.

14. Some other techniques…  Decomposition and recomposition  Pull it to pieces; apply the other techniques; pull back together.  Analogy-based estimation  Detailed review of similar projects; make adjustments.  Proxy-based estimation  Find a well-understood proxy (modules, stories); multiple over entirety.  Software based tools  Loads of packages out there – author has little experience here.  Standardised estimation procedures  Happens in large organisations where there are org-specific processes and guide how specific projects should be estimated.

15. Main take-aways  Communicate – know that estimates inform plans and everyone knows they are different.  Use existing data to help inform future projects.  Don’t over-estimate productivity gains from retrospectives.  Provide confidence ranges – not single point estimates.  Don’t discount simple calculations. If the data is accurate and there’s little subjective interference it’s probably a good measure.

16. That’s it…  Thanks for your time.  Want to drop me a line, ask a question?  @mostrorec  mostro20@gmail.com  Mstrong.info