IT Employment

General discussion


Eliminate the fudge factor in project estimates

By MaryWeilage Editor ·
This week's Application Developer Management e-newsletter explains how the fudge factor is added to project estimates and offers suggestions on how you can eliminate this factor from your estimates. How do you eliminate the fudge factor in project estimation? Do you think you'll utilize some of the advice Scott Withrow offers in this column? Tell us which techniques work for you.

If you aren't subscribed to the Application Developer Management TechMail, visit our e-newsletter subcenter to subscribe to this free e-newsletter:;tag=fb

* Please delete any extra spaces that appear when you paste this link into your browser.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Project Manager needs to understand people and process

by bbeasley In reply to Eliminate the fudge facto ...

Too often I see a project manager does not understand the people or the process involved in solving the problem. This is where the worst fudge factor comes into play. The developer or dba knows that the project manager only cares about the deadline so they buffer their time to cover their butt. The project manager, not knowing what the others really do, accepts what they tell him/her and then buffer it to try cover their own butt.
It is impossible to gain all the detail you will need up front. I also think formalizing project estimation process, while it sounds good to management, falls short of reality except in large projects.
The biggest fudge factor is unknowns and trying to identify where they lay. Unknowns pop up in the following areas: 1) people are new to a business process 2) people are new to a technology 3) technology is new and hasn't been proven 4) project manager has not worked with the people on the project or does not know how they work. Does this mean I can now pinpoint the fudge factor? Of course not, but it does mean I know if a project will have a larger fudge factor than others. I try and minimize this by minimizing the 4 things up above. Particularly when it comes to technology, we need to try and utilize a process that we have used before that has succeeded. Whenever it comes to trying a new technology or utilizing new people we stick to smaller projects where the larger fudge factor is not as heavy an impact. On larger projects we stick to what we know and can succeed with a smaller fudge factor.

Collapse -

Suggestions from a reader

by MaryWeilage Editor In reply to Eliminate the fudge facto ...

Note from the editor: We received the following feedback from member Charles Carroll.

I have a couple of suggestions:

1. Inform all hands (up as well as down) that there are three levels of estimation - ball park, reasonable and accurate and that these are based on the forecasting horizon. Ball park for the whole project or 6 months, reasonable for 1-3 months or the next phase/iteration and accurate for 2-4 week. Acceptable variances are established for each horizon.

2. Use a sliding baseline with earned value analysis based on the "accurate" estimation period. That allows people to learn as they go and you can suggest that estimation of short term work is an indicator of true expertise.

3. Don't confuse level of effort with duration. Estimate in terms of hours of work to be performed. Then introduce availability/effectiveness factors such as time off, attendance at "town meetings," participation of user subject matter experts, etc.

4. Introduce incentives (which means money) for accurate (not necessarily positive) estimation. This is measured over a significant period, say the most accurate estimators for the year. This brings with it the possible risk of padding to ensure "accuracy" so you will also need to be frank about competition with other teams. IT isn't used to this but people in other career fields are. If your estimations are accurate because they are twice as long as every other team doing the same thing, you get your bonus for estimating and your penalty for being the least competent team/person. Most IT people are salaried so the following might not work, but is a thought. An automobile dealer I know used to use standard (from the book) estimates for LOE on repairs. If the mechanic completed the repairs earlier, he got paid for the book estimate. If the car came back, an ombudsman determined whether or not it was for shoddy work. If it was, the mechanic had to complete the repair at no cost to the dealership. This dealership attracted the best mechanics in the area.

5. Paragraph 4 really speaks to using a feedback system with continual posting of results. It has to be accompanied with root cause analysis when an estimate is significantly off. This doesn't have to be a never-ending analysis. Analysis is followed by mentoring and referral to the most accurate estimating team (again, these folks get some type of incentive to help their fellow teams improve).

6. Among the reasons for inaccurate estimation is fear. If I estimate accurately and an unlikely or rare event keeps me from meeting my schedule, I will get hammered. In this case the project or team lead has to support his or her team. Critical events such as non-receipt of equipment, no-shows by non-team participants, power outages, etc. need to be tracked and reported on a frequent (weekly) basis. These events should be subtracted from the estimation. Yes, Mr VP, your expert couldn't make the worksession because she had an unscheduled, important meeting with a client. We understand that. We just want you to know that this will slip task X three days. No hostility on our part; just the facts. The presence of a strong social contract between management and technicians/estimators will remove much of the fear incentive to pad estimates.

Collapse -

Reader disagrees with eliminating the fudge factor

by MaryWeilage Editor In reply to Eliminate the fudge facto ...

Note from the editor: We received the following reader feedback from Seema Raymond:

In Scott's example, the six adjustments made at various levels is 'realistic' and I therefore disagree with the elimination of the fudge
factor, and instead strongly advise the inclusion of the fudge factor!!

Only a developer could estimate, if details of a program go wrong for some reason, how long it will take to get it right. In the same way only the team leader can give an appropriate estimate of how long it will take to link separately developed programs and also how long he'd need to fix it if an issue cropped up. The same goes for the DBA. Issues could crop up at all levels and most of the time they do.

The fudge factor put on by a Project Manger will only be from the point of view of Project Management issues not in-depth detailed issues.

Unlike Scott I have just over 10 years of IT experience, a few years experience of leading modules in a project and most recently have led an
Implementation Project with great success - achieving the planned target date.

Related Discussions

Related Forums