Project estimationBiased advice on producing accurate project estimates and managing expectations with stakeholders.

Morgan Strong

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.

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.

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.

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.

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.

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.

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.

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.

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).

Complexity 2.38 Documentation required 1.52 Database size 1.42

Requirements analyst 2.00 Applications experience 1.51 Platform experience 1.40

Programmer capability 1.76 Software tools 1.50 Architecture and risk 1.38

Time constraint 1.63 Platform volatility 1.49 Precedentedness 1.33

Turnover 1.59 Storage constraint 1.46 Developed for reuse 1.31

Multisite development 1.56 Process maturity 1.43 Team Cohesion 1.29

Required reliability 1.54 Language experience 1.43 Dev flexibility 1.26

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.

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)

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.

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.

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.

That’s it…

Thanks for your time.

Want to drop me a line, ask a question? @mostrorec mostro20@gmail.com Mstrong.info