allaboutxpert.com.au copyright © 2015:all content is the copyright of allaboutxpert australia (pty)...

allaboutxpert.com.au

copyright © 2015: all content is the copyright of allaboutXpert Australia (pty) ltd

PMI Australia Conference

Estimation


introduction

• hi, I am Dennis Grant.

2

• I am the CEO of South Africa’s largest independent Project Management Company.

• I am a 15 year old “accidental Project Manager”.


accidental Project Managers – why?so I wonder just how many accidental Project Managers are

here today?

3

• very few people leave school wanting to be a Project Manager.• in South Africa there are no under graduate courses in Project

Management, yet you can do your Masters and you can do your Doctorate.• people often start other careers in IT, Engineering, etc. and evolve into

Project Management. • often this is initiated in terms of moving into a management role and/or

moving into a management pay grade.


so how did I approach my first estimate?

4

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

Expert Judgement

BroadbandDelphi

Program Evaluation and

Review Technique

(PERT)

copyright © 2015: all content is the copyright of allaboutXpert Australia (pty) ltd 5

I soon became a statistic……..the Standish Group “Chaos” report shows:

these findings have been

fairly consistent for

the last 25 years

31.1% ofprojects willbe cancelledbefore theyare evercompleted

52.7% ofprojects willcost 189% oftheir originalestimates

only 16.2%for softwareprojects thatarecompletedon-time andon-budget

projects completedby the largestAmericancompanies haveonly approximately

42% of theoriginally proposedfeatures andfunctions

• the cost of these failures and over runs are just the tip of the iceberg. the lost opportunity costs are not measurable, but could easily be in the trillions of dollars.

• even when these projects are completed, many are no more than a mere shadow of their original specification requirements.

Source: Standish Chaos Report


and would likely remain a statistic ……..

PricewaterhouseCoopers

, which reviewed 10,640

projects from 200

companies in 30

countries and across

various industries, found

that only 2.5% of the

companies successfully

completed 100% of their

projects

http://teamgantt.com/blog/2014/07/21/seven-shocking-project-management-statistics-and-lessons-we-should-learn/#sthash.pDQqPcz2.dpuf

A study published in the

Harvard Business

Review, which analyzed

1,471 IT projects, found

that all but one in six

projects had a cost

overrun of 200% on

average and a schedule

overrun of almost 70%.


The failure rate of

projects with budgets

over $1M is 50% higher

than the failure rate of

projects with budgets

below $350,000


Sadly the trend is

towards more failure


I figured out what was going on…..

concept evaluatio

n

detailed design

high level design

build, test and fix

implementation

non involvement of userinadequate communication

inadequate planning

inadequate definition

bad / poor estimating

incorrect scheduling

numerous changes

inadequate control

poorly planned teaming

inappropriate projectmanagement approach

unsupportivetop management

failure to usesystems approach

wrong project manager

misuse of management

techniques

and importantly where the really bad “stuff” happens


some principles that drive success ….

planning is key

8

time

reso

urc

es

+

-

t2

t1

additional work for planning and structuring the project

extra effort and rework prevented due detailed upfront planning

increasing the effort in planning and structuring projects leads to cycle time (t2 < t1) and total effort reductions

of 35% - 50%

8



ability to influence is at the beginning of a project

and not when things go

wrong

9

knowledgeacquisition

conceptinvestigation

basicdesign

prototypebuilding

pilotproduction

manufacturingramp-up

index

of at

tenti

on a

nd

influen

ceability toinfluenceoutcome

senior management involvement in projects must be focused on the initial stages where the strategic

direction and objectives are defined

actual management

activity profile

9



perceived capacity is

always greater than real capacity

10

maintenanceday-to-day

majorprojects

admin

perceived supply

real supply

majorprojects

minorprojects

admin

maintenanceday-to-day

perc

ent

of

tim

e s

pent

real innovation capacity

perceived innovation capacity full capacity (100%)

minorprojects

the real allocation of time to task categories must be assessed to bring resource demand created by projects

in line with real innovation capacity

10


where do Project Managers come from?

11

The Sydney

Opera House

strategist /

imagineer

organiser / stalwart

or preserver

socialiser /

empathiser

realist / analyst

not everyone is good at planning or estimation

those that can execute a plan

+- 70%

those that can come up with a

plan

+- 30%

11


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 dependent on the experience and knowledge of the project manager.

there is no central repository for recording estimates.

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

generic problem statement

estimation is inconsistent and ever changing

12


generic problem statement - detail

the above issues result in variances in time, cost and effort when compared to actuals

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

PEOPLE

• 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 dependent on the forecasting and budgeting process, which is financially driven rather than size driven.

PROCESS

• lack of historical information.• lack of industry benchmarks.• lack of a central repository for storing estimations and assumptions.

• estimation process is dependent on the requirements process, which is new and slowly maturing within the organisation.

• no standards exist in terms of sizing (function point count).

SYSTEMS

PRACTICE

13


a science that drives effective estimation

• Parametric Estimation

– some great examples:

Seers

SPR

etc.

• sizing is the key input to any estimate.

• complexity affects productivity ratio’s.

• environments affects productivity

ratio’s.

• processes affects productivity ratio’s.

• bottom up is better then top down.

14


positioning 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 – Proxy• 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 conceptphase

Technique - Analogy• Optionally–using to

size and estimate projects where very littlie information is available.

Inn

ovati

on

Pro

ject

Lif

ecycle

Estimation Confidence Factor50 – 60%

Estimation Confidence FactorMiddle of Detailed Design = 60%End of Detailed Design = 85%

Estimation Confidence FactorActual = 100%

Estimation Confidence Factor20-40 %


most things can be sized

analogy sizing• estimates can be made against a

variety of software products in the table, further categorised by size (small/medium/large)

• the portions of enhancement projects that are new, enhancement, maintenance, and conversion effort are recorded here

proxy sizing• 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

metric sizing• function points (recommended)

confiden

ce

documentation

facilitation

Copyright © 2015: All content is the copyright of allaboutxpert (pty) ltd and/or allabout projectmanagement (pty) ltd

Project Estimation Process

Schedule and Summary Estimation report sent to

Project Manager

PMT

Estimation Team finalise estimation output and

reporting

Estimation Team and PM + key project resources meet for

estimation workshop – facilitated for larger projects/programs

Environmental Assessment Questionnaire completed and submitted with required

project documentation

PM updates estimation output with current knowledge and compares to current project schedule, updating where he

deems necessary

Updated schedule ready to be baselined

Estimation request submitted to call centre

Support documentation and request for documentation

sent to PM

If iterative updating of estimation output are

required, PM to request from estimation team

If no updates planned or final output accepted and signed

off ->

17


Project Management cost and effort benchmarks


the common sins of Estimation

confusing estimates with targets: early estimates are often used as the “bogy” point but soon develop a life of their own. ROM vs. reality!

saying yes when really meaning no: vigorous, job-defending estimation with little data or quantities. young, junior, introvert software engineer vs. sales person who is more experienced, senior, and extrovert.

committing too early with lots of uncertainties: “cone of uncertainty” means that the uncertainties decrease as the project progresses. early in the software development lifecycle there is a tendency to underestimate. estimate early and estimate often!



estimating in the “impossible zone“: schedule compression increases the total cost or effort for the project. “impossible zone” is a compressed schedule with a zero chance of success. “where no man has gone before.”

taking credit for increased productivity BEFORE you achieve it: assume the productivity loss from initial use of new tools or methods considering learning curve and error-proneness.

using only one estimation technique: estimate with different ways and looks. multiple approaches contribute to Brook’s “vigorous defense”. same picture different camera angle.



not using estimation software: it can bring more credibility providing a sanity check against completed projects. science of estimation is supported in the tools.

not including risk impact: remember Murphy’s Law? “anything that can go wrong will go wrong.” risk exposure is where “risk buffer planning” starts.

providing off-the-cuff estimates:• treat estimation as an essential task. even simple arithmetic is better than

guessing or intuition.• document your assumptions and knowledge. • define a standardised estimation procedure (multiple approaches,

description of imprecision, re-estimate schedule, point of estimate becoming commitment).

• decompose big estimates into smaller ones (system-modules).


a practical walkthrough of the estimation process


thank you

allaboutxpert.com.au copyright © 2015:all content is the copyright of allaboutxpert australia (pty)...

Documents

accidental project managers

projects http

failure rate of projects

management role andor

cost overrun

standish chaos reportcopyright

standish group chaos

schedule overrun