7 signs of bad project estimates - and how you can fix it

Kolinger Associates, LLC 2010 All Rights Reserved

7 Signs You Have a Bad Project Estimate(And what to do about it)

January 20th, 2010

Presenter

Presentation Notes

Topic: Seven Signs You Have a Bad Project Estimate...and What You Can Do About It Details: Failure rates of software and IT projects are abysmal. Industry studies reveal that only 1 out of 5 software projects is likely to bring full satisfaction. Project reviews keep identifying the usual suspects of poor communication, underestimation, and scope creep as the cause for failure. Typically these problems are symptoms, and not root causes. This interactive, facilitated working session will uncover significant lessons learned in project estimation, but with a focus on the root causes of estimate failure. Group exercises will give participants an opportunity to apply their knowledge and bring effective solutions for prevention, recovery and success back to their jobs.


Today’s PresentationEstimating project cost and schedule is a serious challenge to our companies.

Common symptoms include projects that refuse to end, projects cancelled, people overworked, missing a window of opportunity for a new product, and overruns causing an inability to fund other important initiatives.

Tools may help - but this presentation is primarily about the ideas and concepts necessary for improvement.

Presenter

Presentation Notes

Project estimation is a topic that seems to get more attention than ‘better management tips’. But as we think about it, estimating is a component of better management. This is about negotiating for a better project. We'll discuss specific secrets of delivering more valuable software to customers despite having fewer resources. What helps estimate quality? That’s what this presentation is about – creating a better estimate. Fighting the frenetic business that is pervasive. Take the necessary time to create a viable estimate.


Overview• This presentation considers factors that are common to most but some

specific references to software development estimation.• Me: 25+ years, mostly in large corporations. Developed software,

consulted, trained, managed – and recovered - scores of projects. • Founded OfficeWork Software in 2005.

Presenter

Presentation Notes

My company spent over $5 million on my education. I was trained by the best people in the business. My background includes computer operations, programming, managing projects, corporate process improvement, measurement, quality assurance, methodology development, consulting, and sales. My specialty is guiding teams and coaching project managers to be the best. At the largest utility in California I was known as ‘Mr. Project Management’. I mention this because these experiences shaped my views on PM. I’ve seen fortunes spent on IT projects: Large, medium, and small. I’ve seen lots of money spent; I’ve spent other people’s money, and I have the distinction of having spent my own on software projects. (TurboProject, FormTool, and OrgChart Professional). So my experience is very real and varied. I am an American, but had the privilege of growing up in England and Switzerland. My wife is half-Japanese. My company’s software development teams are in India and Russia. So I have had a lot of exposure to other cultures, their values, preferences, communication styles, and work habits. Most of what I have to say transcends culture. Project Management is often referred to as the ‘accidental profession.’ Nobody goes to school (as far as I know) and says, ‘When I grow up I’m going to be a project manager.” No. Interestingly the profession attracts some of the best talent and pays some of the best salaries, but it is an accidental profession. Me? Dropped out of a college pre-med major, moved 10,000 miles from home to join a rock and roll band, went back to college, became a psychologist, went into software development, sat next to a boss who managed projects, got roped into managing projects, helped other projects get unstuck and complete their projects… And I was just minding my own business! The management guru, Peter Drucker puts it like this: Planning doesn’t work. You can prepare yourself, learn what you ought to know, and expand your experience and professionalism, but ultimately, he said, “opportunity comes in over the transom”. In this presentation I believe there are fundamentals that will help you be prepared for exploiting the opportunities that come ‘accidentally.’. The soul of a Project Manager: I believe there is something that must be apprehended deeply in a the project manager if they are going to fill the job properly. There is a passion and calling that this job requires to do it well. Ability and knowledge – as important as they are - are not enough. A PM looks at things differently. They get a hold of the big picture and have a knack of guiding a team to a useful conclusion. They focus and process everything in a different way. Some of the points in this presentation give an indication as to what this mentality includes. So I tend to communicate using academic research, real work success and failure (which gives great learning opportunity), human foibles, cartoons, and funny sayings. My personal tendency is to swing like a pendulum, going from the intense, super-serious and sublime before swinging to the ridiculous. But the points made in this presentation are very serious and very powerful. There are already scores of great books on PM. I wish I had written some of them. But, I guess if I had my way, I would write a cartoon book about this topic. Companies FORGET their greatest asset. As IF people mattered. The Secrets to Successful Strategy Execution Research shows that enterprises fail at execution because they go straight to structural reorganization and neglect the most powerful drivers of effectiveness—decision rights and information flow.


Bad Estimates Very Common

• 67% of all projects under-planned by 290%• 1% of projects meet time, budget, and scope goals• 60% of all projects over 50k Lines of Code cancelled before

completion.• Common gripe: “<<your organization>> does not deliver”

A “Bad Estimate” working definition: Money got spent and the required result was not achieved in time.

A few sundry findings:

(82.3% of all statistics are made up on the spot. Just kidding.)

Presenter

Presentation Notes

Tales abound of the challenges of predicting and controlling the success of software projects. I'm sure this is understood by most in this audience. Why do project managers estimate at the drop of a hat? Genetic Mutation! DNA Code reads: Have project - will estimate - no information needed


The Saga1. Sufficient assets are not allocated, and there is not enough time.

2. The schedule (if there is one) starts to slip, one day at a time.

3. The project manager suddenly realizes the slippage and seeks a culprit.

4. People from various departments involved accuse people from other departments of delaying the project. More time is wasted in finger-pointing.

5. To make up time, the project manager decides to “crash” the project by applying more assets/resources to all activities that are currently being performed.

6. Everyone scrambles to crash his job, and people are infuriated to find out that they are either further behind or finished and their part is not yet needed. Interest wanes as people chafe under the new delays. The project is over-budget due to all the crashing, and the whole thing is either:

– a. on-time but shoddy, – b. well-done but late, – c. both shoddy and late, or – d. abandoned.

Dr. Robert Graham – Project Management as if People Mattered

Presenter

Presentation Notes

Here is what we’re going after – insufficient resources at the beginning of the project. Then … Must keep the estimate valid throughout the lifecycle. This means we will need to watch out for trouble on the way to the deadline. Commit v capability Focus on quality - better time Speed is a way to get into trouble. Fix culture. Why do people give bad estimates? (exercise) You want better estimates? Fix your SYSTEM!!!


QuestionThink of a recent project, that went over budget, was late, or fell short of the original scope.

– Why did that happen? – What could you have done about it?

(Write down your answer)

Presenter

Presentation Notes

Ask what method they use. Analogy, formula, atomic Here we are looking for signs that the culture and people are impacting the results Mistrust, not serious, not congruous, don’t know how. Operational definition (so they know how to meet your requirements) Accuracy, completeness, clarity. People Process Tools What are the consequences for bad estimates? Could it be that there are rewards for bad estimates? Or could it be that the estimate is not the problem as much as the management of the project – and the logarithmic problems with adding more people? How much do you really know about your deliverable and the team (adversity v capability)


Test Your Estimation IQ

Answer: Genetic Mutation!

Question: Why do IT Project Managers estimate at the drop of a hat?

• Have Project• Will Estimate• No Requirements Needed!

Actual Project Manager DNA !

Warning: Do not ride in the elevator with your project sponsor! (Hint: You might rattle off an estimate!)

Gopal Kapur, Center for Project Management

Presenter

Presentation Notes

The point here is that there is a natural optimism that project managers and technical people have. Programmers love to solve problems – they are optimistic about their abilities and do not factor in the interruptions.


Question?

1. How many of you have managers who pressure for cost and date estimates before requirements are clear?

2. How many of you are those managers?3. What are you doing to encourage better

estimating?4. How is it going?

Presenter

Presentation Notes

Show of hands please. It’s not my problem. – Yesy it is – you are the PM Wrong. It is your problem. You’re the PM.


Let’s Estimate!The Project (Input):Web-based information system. (Legacy system already exists; let’s just make it web-based)

The Estimate (Output):

– 12 months– 4.4 FTE– 5,600 hours– $400,000

“We will have it for you in 12 months”

The Estimation Process(Magic wand)

Presenter

Presentation Notes

Consider 1. how well defined is the project, 2. who is making the estimate, 3. how difficult the assignment is NOTE: there is no magic estimation process. You need to understand your project and people.


What to look forSo, how can you recognize the bad estimate…before you get bit?

12 months4.4 FTE5,600 hours$400,000

Presenter

Presentation Notes

And you will regret it if you answer hastily before taking adequate time to estimate 2 things: Project adversity vs management capability. But we will give you a few things to do that will make you look good.


1. When You Hear ‘Done’ More Than 4 Times.

•Project ‘success’ is meeting expectations. Period. •Common finding:

– Everyone ‘knows’– Nobody agrees

•Define the project – in writing - one-pager: – Description: (What, where, when, how much)– Desired Results: (Benefits that will be achieved)– In Scope / Out of Scope – Assumptions

•De-babelize –Use language everyone understands•Sign-off from the sponsor and each stakeholder is critical.

(Harder than it sounds)

So, what the heck does ‘done’ look like?Look for a clear, written definition of the end-result.

Presenter

Presentation Notes

Clear requirements – need to take the time to do operational definitions of what’s required. Careful - Customer / Sponsor tends to forget what asked for – or others forget. WHAT you estimate HOW you do it. Both are critical.


2. When you Hear, “What is the Plan?”

• The plan includes, but is more than the project schedule• The plan includes the project definition, the people, a WBS (Work Breakdown

by deliverable), estimates, resource assignments• Milestones and activities are connected (or linked) so that a critical path can be

identified and managed. • Connections are critical as they indicate hand-offs from one person to another.• Each deliverable has an owner• Each person on the team is associated with a deliverable• Have an independent group review the plan. (Find bug on paper vs.

production).

The estimate is based on the plan. Look for the plan with evidence of traceability to the project definition and make sure everyone is aware.

If you ever hear people saying, “I don’t know what the plan is”, take action!!

Your job as project manager is to keep everyone honest to the project’s schedule, scope, and budget. Even if the estimate were ‘perfect’ you can render it useless through a poor plan.

Presenter

Presentation Notes

Must spend time on this plan. It’s the first thing in the system. Plan (capability v adversity) - > estimate - > result


Clue: Missing Dependencies

In this case, ‘date’ was the primary goal

Presenter

Presentation Notes

There’s a style of using MS-Project – and other tools – where dependencies are not specified. Instead the program is used a a task list. There is not a network diagram, so all of the resources can easily be bunched up.


View resource graph and Gantt


Review usage in excel


3. When You Have a Single Number Estimate

Two critical lessons:1. Projects are bigger than they appear.2. The road to project hell is paved with single number estimates.

Best Case Worst CaseMost Likely

Look for a schedule based on appropriate estimate ranges

Gopal Kapur, Center for Project Management

Software is “different”

Presenter

Presentation Notes

We use ranges because of the inherent uncertainties in SW development. Remember the bronzing machine. What happens when you give a date range? Client only hears the early date. Single numbers will force a need to go faster than feasible.


Estimating Confidence in Software Delivery

Observed Limits of Estimate Accuracy

0.67x

0.8x1.0x

0.5x

0.25x

2x

4x

1.5x

1.25x

Initialproduct

definition

Approvedproduct

definition

Requirementsspecification

Productdesign

specification

Detaileddesign

specification

Productcomplete

Project cost(effort and size)

Projectschedule

0.85x

0.9x1.0x

0.8x

0.6x

1.25x

1.6x

1.15x

1.1x

Com

plet

ion

Underestimated

Overestimated

+ 400 %

- 400%

Exact 0%

Effort Duration

Best WorstMost Likely

10% Chance

50% Chance

90% Chance

Sizing

Rough

Fair

B. Boehm – SW Engineering Economics

Presenter

Presentation Notes

So never mind NASA. What are your company’s numbers? What does the curve look like - if we were to plot project estimates vs. actuals after each project? We could identify the activities that enable us to see the end more clearly. AND we would be positioned for measured improvement. Remember: if you can’t measure it, you can’t control it! Or improve it.


4. When It Has Not Been Done Before Look for an estimate that factors your capability

Project management is all about making promises and keeping promises.

Promises are more likely to be kept if:

• Made voluntarily (you agree)

• It’s your commitment (your data)

• it is according to capability (i.e., you have proven ability)

Include Risk Management (Project Management for Adults)

To maintain a viable estimate constantly manage project adversity and team capability

Stan Rifkin – Master Systems

Tom DeMarco - ASG

Robert Charette - ITHABI

Presenter

Presentation Notes

Be careful about making any promises about anything you have not done before. What you ensure = Commitment according to capability. This is where you can easily exceed your capability.


5. When You Can’t See Evidence of Historical Data

• The estimate should consider a reasonable work week for resources based upon historical data for individuals and the organization.

• Examples:– 60% productivity or 24 hours/week/person– Individual characteristics

• Technical skill factor• Business knowledge factor

– Careful use of overtime– Defect and rework rates

Look for an estimate that uses historical performance data as a reference

Only lunch breaks are 100% productive

Presenter

Presentation Notes

Hey - SHOW YOUR WORK! I am simply shining a light on an area where numbers have been tough to obtain. It does not matter what industry numbers are – you need your own – then management will listen. I gathered 3 years of data - .6 productivity factor. Dedicated personnel. What are your numbers? The end of the metrics program happened when the district manager said he didn’t want to see any non-productive time.


Efficiency


Question

• What percent of a programmer’s time is spent coding?

• How is this factored into the estimate and schedule?

Presenter

Presentation Notes

Programmers – when they give you an estimate it probably does not factor in all of the other commitments/activities. You must guard this as a PM


What do Programmers Do?

Presenter

Presentation Notes

So if your software project calls for 40 hours of effort, this could be 8 weeks of duration. Programmers say take my estimate and multiply by 2 … or 3 … that’s because of all the interruptions!


Look for a Repeatable Estimating Process

Historical data is only valuable (normalized) in the context of a repeatable process

Presenter

Presentation Notes

So you have a scheduling tool. What are you going to put in it? The schedule tools do not address the issues that feed it. ESTIMATING SOMETHING NEW METHOD DFSS – design for six sigma Plan – must include capability and adversity Fundamental to determining the estimate.


Estimation Methods

• Formula• Activity-based• Analogy


How to Estimate(Kapur “Flinch” Method)

$850B …. For PHASE 1 !


Balancing the Estimate

Your Goal: Commitment according to capability!


Project Difficulty vs. Management Capability

Project: Web-Enabled Business Information System

Presenter

Presentation Notes

Programmers are not thinking about all the details at the time of estimate. Neither are you. Use a good checklist to profile adversity vs. capability What would you add to the last project that might have helped better assess the estimate? So this is our little project with the magic estimate. Let’s watch what happens with the over-optimism.


Historical Data: Example of Estimating Maturity

Observed Limits of Estimate Accuracy

0.67x

0.8x1.0x

0.5x

0.25x

2x

4x

1.5x

1.25x

Initialproduct

definition

Approvedproduct

definition

Requirementsspecification

Productdesign

specification

Detaileddesign

specification

Productcomplete

Project cost(effort and size)

Projectschedule

0.85x

0.9x1.0x

0.8x

0.6x

1.25x

1.6x

1.15x

1.1x

6. C

ompl

etio

n

Underestimated

Overestimated

Idea / OP

10/1/02~ 392% Variance

FTE 4.4

H/L Requirements

9/1/03~ 317% Variance

FTE 4.4

Most Code Complete

3/1/04~ 33% Variance

FTE 13.4

- Effort / Budget

- Schedule

LegendProject Complete

8/2/04

FTE 17.9Requirements Complete *1

2/1/04~ 80%Variance

FTE 10.0Footnote: * 1. Independent Estimate at point of most requirements complete

+ 400 %

- 400%

Exact 0%

Effort Duration

Presenter

Presentation Notes

So never mind NASA. What are your company’s numbers? What does the curve look like - if we were to plot project estimates vs. actuals after each project? We could identify the activities that enable us to see the end more clearly. AND we would be positioned for measured improvement. Remember: if you can’t measure it, you can’t control it! Or improve it.


Estimation Accuracy Commercial Web System

An Example of Estimating [Im]Maturity

Project Milestone

OP / Idea (Forecast)

H/L ReqDone

(Forecast)

Most Code Complete (Forecast)

Project Complete (Actual)

Date of Estimate 10/1/02 9/1/03 3/1/04 8/1/04 FinalEffort Hours 5,600 unknown ~ 16,000 25,000Cost 402,000$ 475,000$ 1,484,429$ 1,979,238$ Cost Variance 392% 317% 33% 0%FTE 4.4 4.4 13.4 17.9FTE Variance 311% 311% 33% 0%

Presenter

Presentation Notes

Here it is in table form Estimate off by a factor of 4


Where did the money go?

How much waste? ~60% Re-work!

$560k $620k

$280k

$100k$20k

Pay to take bugs out.

Pay to put bugs in.

Presenter

Presentation Notes

Defects -


Quality Results Defects Found Pre and Post Implementation

1. Defects Discovered in Testing (after “Code Freeze”):

Code defects: 977 (70%)Missing / Incorrect Requirements: 394 (30%)Total: 1,371

2. Defects Discovered by the User in Production:

First 90 days: 136


Better Estimation via Better Control of Quality Comparing Defect Removal Results of Two Projects

Case A Case B

Activity (Dollars) (Person Hours) Defects (Dollars) (Person Hours) Defects

Top-Level Design Review $2,875 115 50 $0 0 0

Detailed Design Review $17,500 700 140 $0 0 0

Code Inspection

$42,500 1,700 110 $0 0 0

Unit Test $19,250 770 50 $38,000 1,500 125

Integration Test

$62,250 2,490 100 $107,205 4,290 190

Total $128,625 5,775 450 (90%) $145,250 5,810 315

Maintenance $325,000 13,000 50 $797,500 31,900 185

Lifecycle Total $453,625 18,755 500 $942,750 37,710 500

Reference: Capers Jones, SPR

Cheap

Expensive

Presenter

Presentation Notes

The things we do to give us the illusion of going faster. Sometimes we need to slow down in order to go faster. Better estimating is not just coming up with the perfect number. I has to do with understanding the economics of software engineering. How can you get me a better number. What can you do the lower the cost? What can you do to bring in the schedule? What are my tradeoffs? Spend your money a bit differently, and get a very different result. This slide basically shows the real cost to skipping good software engineering practices. It’s very very wasteful. How much of this is FFIC dealing with?


Question – Crash Schedule?

• What happens when we compress the schedule?

• Good to know when devising a plan that will work – and some exec asks for it sooner than you can deliver.

• You need to know the minimum development time.

Presenter

Presentation Notes

Let’s add people and see what happens – complexity of communication and learning curves adds a lot of expense w/o much benefit


Crashing the Schedule


Effects of Schedule Compression - 1

100 KLOC

11

$1.5 MM

23 months

2.7 days

Project Size:

Team Size:

Cost

Duration

MTTD:

Optimized Compressed

QSM

Before

Can we go faster with more

people?

What’s the effect of a 15% schedule reduction?


Effects of Schedule Compression - 2

100 KLOC

11

$1.5 MM

23 months

2.7 days

Project Size:

Team Size:

Cost

Duration

MTTD:

Same

24

$2.7 MM

20 months

1 day

Optimized Compressed

QSM

AfterBeforeWhat’s the effect of a 15% schedule reduction?

Worth it? Really?


Effects of Schedule Compression - 3 Quality Considerations

Def

ects

/ M

ista

kes

Time

23 Months20 Months

• An individual’s learning curve must be accounted for in a shorter schedule. • There is a minimum development time!

A B


Software Development Effort - 9 ProjectsIntenseIntense Schedule PressureSchedule Pressure

CostSchedule


Deadline Effect


Improving Process Reduces Costs

For a typical software system, consisting of 500K Lines of Code:

Stan Rifkin, Master SystemsLarry Putnam, QSMRay Dion, Raytheon

SEILevel

IIIIIIIVV

Effort(P. Mos.)

16,3626,4681,876

866342

Defects(Number)

25,0699,9092,8741,326

524

Total Cost(Mill. $)

163.364.718.8

8.73.4

Significant savings as a result of achieving Level 2

Most of these improvements come from better project management!


Right-sizing ... or Dumb-sizing?

Mark Blaxill, The Fallacy of the Quick Overhead Fix, July 1991 Harvard Business Review

Bureaucratic Robust

Two Competitors, Same Products, Same Sales Revenues, Different Cultures

Fixers63%

Process Improvement

13%

Core Management

24%Fixers

29%

Process Improvement40%

Core Management

31%

Total Employees = 152 Total Employees = 80


Main Build – Estimated Duration


Main Build Time - 9 Projects

ESLOC (Thousands)

Industry Average

Months D

urationHistorical DataHistorical Data


Main Build Effort - 9 ProjectsPerson M

onths

ESLOC (Thousands)

Historical DataHistorical Data


Project Staffing Comparisons

0.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

A B C D E F G H I J K

Projects from ABC Division

Benchmark Peak Staff

Company Peak StaffProjects from XYZ Division

61%

108%

77%

64% -11%

180%

-25%-8.3%

0%

0%0%

Percent by which this project exceeds the typical business systems average staffing


A Business Case for Process Improvement at Company X

SEI

Level

Calendar Time

(Mos)

Effort

(PMos)

Defects Total Cost (1,000s)

Discovered Shipped Median Lowest Highest

I

II

III

IV

V

18

11

9

7.5

5

67

16

9

5

2.5

297

71

40

22

11

11

3

1

1

0

614

148

82

44

23

202

109

58

32

5

20901

196

105

57

31

50 KLOC, Productivity Index (PI)=15, MBI=0.2


Benchmark Power

One company could save $7 million in a portfolio of 14 projects by making the right improvements in their management approach. In addition, this portfolio of projects would finish 3.5 months sooner and with a much higher reliability/quality. This remarkable analysis is made possible by using the high-performance benchmark database and SLIM toolset.


Know your capability !!!

Commitments must be tempered with known capability!

Question:

• For your current project, where would you look for a mismatch of commitment and capability?

• How should you respond?

Project Difficulty Management Capability


6. When You Have to Micro-ManagePeople - Place them where strengths are leveraged, and their weaknesses really don’t matter.

– People aren’t fungible – Consider:

• 85% feel they are in the wrong job • 10% are in their dream job• 95% confess they lie on the job

– Misplaced people will disrupt– Fear repels learning and improvement– Focus on developing strengths not fixing weaknesses– Company slogans and performance reviews demoralize

“It’s time for performance review!”

“Malicious Compliance” – be careful what you ask for! You might get it!

Presenter

Presentation Notes

This is HUGE. A goldmine. What do you believe about people? Theory X, Y? People are individual and have unique strengths. Consider snowflakes. People working out of passion is critical. Sense of destiny and purpose. Challenged people to THINK Culture of discipline (accountability and discipline) Someone lost … is out of place Tell Story of Thomas Watson – trained people – gifted. Depends on the knowledge of the people. Helps if they like you and want the project to succeed. Stress Strengths – vs fixing weaknesses. Stress Speed – and you will get that!


7. When You Hear Any Answer That Starts With, “Well …”

• A ‘perfect’ estimate is valid as long as you manage to the plan.• Avoid use of ‘percent complete.’

– Remember the “90:90 Rule of Project Tracking.”• The first 90% of the project takes 90% of the work.• The last 10% takes the other 90%!

• Do not be bamboozled in project reviews! Verify:– 1. Do we have the right people?– 2. Do we have a good plan?– 3. Are we going to make it?

Look for effective project reviews and the signs of being off-track


“Relax – We’re 90 Percent Complete!”

Traditional software progress measures do not provide visibilitySoftware Engineering Economics, Boehm – pp 608


7 Signs – A Review1. When You Hear the Word ‘Done’ 4 Times.So, what the heck does ‘done’ look like?

2. When You Hear, “What is the Plan?”Look for the plan with evidence of traceability to the project definition and make sure everyone is aware.

3. When You Have a Single Number EstimateLook for a schedule based on appropriate estimate ranges

4. When It Has Not Been Done BeforeLook for an estimate that factors in data of your organization’s capability

5. When You Can’t See Evidence of Historical DataLook for an estimate that uses historical performance data as a reference

6. When You Have to Micro-ManageGet the right people in the right place

7. When You Hear Any Answer That Starts With, “Well …” Look for effective project reviews and the signs of being off-track


Conclusion

• Radical improvement is possible• Information is not enough• Needed:

1. Invest in knowing your capability2. Learn to make commitments according to capability3. An outside perspective may help

You must protect your company from a bad estimate


Acknowledgements

• Gopal Kapur – Center for Project Management• Dr. Stan Rifkin – Master Systems• Dr. Robert N. Charette – ITABHI Corporation• Dr. Barry Boehm - USC Center for Software Engineering • Dr. Gerald Chester – Strategies@Work• Dr. Michael Deutch – Hughes Aerospace• Dr. Robert Graham - SMC• Tom DeMarco – Atlantic Systems Guild• Larry Putnam, Sr. – Quantitative Software Management• Dan Swaigen – PM Connect• Gordon Landies – GL Ventures• John Maher, CPA – Maher Accountancy• Dennis Peacocke – SCS• Alan Lashbrook – AT&T• Ron Linski – Alliance Business Consulting• Betsy Guthrie - Autodesk

My thanks to the following individuals who have made important contributions to the body of knowledge presented in this document.


About Us

• Process assessment and development• Planning and Estimating Training• People Assessment• Rescue Off-Track Projects• Tools Training and Implementation• Project Reviews

Contact 415-246-7264 – [email protected] - www.kolinger.net

Kolinger Associates provides solutions and advice for better estimating and managing large projects. With our help you will …

Spend your money a little differently … and get a much better result.

mailto:[email protected]

7 signs of bad project estimates - and how you can fix it

Business

project definition

project schedule

project managers

project cost

project input

recent project

project success

bad project estimateand