Do you inflate your estimated project completion dates?

Question

Do you inflate your estimated completion dates? If so why? How much?

I tend to inflate mine a little because I can be overly optimistic.

Answer 1

Take whatever estimate you think appropriate. Then double it.

Answer 2

Oh yes, I've learnt to always multiply my initial estimation by two. That's why FogBUGZ's Evidence-Based Scheduling tool is so really useful.

Answer 3

Oh yes, the general rule from long hard experience is give the project your best estimate for time, double it, and that's about how long it will actually take!

Answer 4

I wouldn't say I inflate them, so much as I try to set more realistic expectations based on past experience.

Answer 5

If you inflate your estimate based on past experiences to try and compensate for your inherent optimism, then you aren't inflating. You are trying to provide an accurate estimate. If however you inflate so that you will always have fluff time, that's not so good.

Answer 6

Typically yes, but I have two strategies:

1. Always provide estimates as a range (i.e. 1d-2d) rather than a single number. The difference between the numbers tells the project manager something about your confidence, and allows them to plan better.
2. Use something like FogBugz' Evidence Based-Scheduling, or a personal spreadsheet, to compare your historical estimates to the time you actually took. That'll give you a better idea than always doubling. Not least because doubling might not be enough!

Answer 7

Joel has a great article about Evidence Based Scheduling.

Answer 8

A good rule of thumb is estimate how long it will take and add 1/2 again as much time to cover the following problems:

1. The requirements will change
2. You will get pulled onto another project for a quick fix
3. The New guy at the next desk will need help with something
4. The time needed to refactor parts of the project because you found a better way to do things

Answer 9

It's not called "inflating" — it's called "making them remotely realistic."

Answer 10

I wouldn't say I inflate them but I do like to use a template for all possible tasks that could be involved in the project.

You find that not all tasks in your list are applicable to all projects, but having a list means that I don't let any tasks slip through the cracks with me forgetting to allow some time for them.

As you find new tasks are necessary, add them to your list.

This way you'll have a realistic estimate.

I tend to be optimistic in what's achievable and so I tend to estimate on the low side. But I know that about my self so I tend to add on an extra 15-20%.

I also keep track of my actuals versus my estimates. And make sure the time involved does not include other interruptions, see the accepted answer for my SO question on how to get back in the flow.

HTH

cheers

Answer 11

I wouldn't call additional estimated time on a project "inflated" unless you actually do complete your projects well before your original estimation. If you make a habit of always completing the project well before your original estimated time, then project leaders will get wise and expect it earlier.

Answer 12

You can calculate project durations in two ways - one is to work out all the tasks involved and figure out how long each will take, factor in delays, meetings, problems etc. This figure always looks woefully short, which is why people always say things like 'double it'. After some experience in delivering projects you'll be able to tell very quickly, just by looking briefly at a spec how long it will take, and, invariably, it will be double the figure arrived at by the first method...

Answer 13

It's a better idea to add specific buffer time for things like debugging and testing than to just inflate the total time. Also, by taking the time up front to really plan out the pieces of the work, you'll make the estimation itself much easier (and probably the coding, too).

If anything, make a point of recording all of your estimates and comparing them to actual completion time, to get a sense of how much you tend to underestimate and under what conditions. This way you can more accurately "inflate".

Answer 14

Many people here are saying make an estimate and double it (and sometimes double it again). Others are saying use Evidence Based scheduling (al la Joel).

When I'm estimating a project, there are four components for each task:

1. My best guess as to how long it will take.
2. The uncertainty (risk) - like perhaps there is something (an known/unknown unknown) not in the spec that will double the time.
3. Bug Fixes
4. Contingency Time

For #1, I use the most realistic estimate I can.
For #2, I decide the probably of the risk and then multiply #1 by that an get an adjusted estimate,
For #3 and #4 I multiply the adjusted estimate by 20% and that become the value of each.

So for any task, the final total is 140% or more of the original estimate.

For the whole project, the contingencies and bug fixes get collected up into two separate tasks and eaten into as the project progresses.

Of course that's not including testing which I typically make equal to the total value for each task.

Answer 15

What are your estimates based on?

If they're based on nothing but a vague intuition of how much code it would require and how long it would take to write that code, then you better pad them a LOT to account for subtasks you didn't think of, communication and synchronization overhead, and unexpected problems. Of course, that kind o estimate is nearly worthless anyway.

OTOH, if your estimates are based on concrete knowledge of how long it took last time to do a task of that scope with the given technology and number of developers, then inflation should not be necessary, since the inflationary factors above should already be included in the past experiences. Of course there will be probably new factors whose influence on the current project you can't foresee - such risks justify a certain amount of additional padding.

Answer 16

This is part of the reason why Agile teams estimate tasks in story points (an arbitrary and relative measurement unit), then as the project progresses track the team's velocity (story points completed per day). With this data you can then theoretically compute your completion date with accuracy.

Answer 17

a friend of mine once told me that he uses this algorithm:

1. make a estimate
2. express it in the biggest time unit you can, without going under the value 0.5
3. let's call it x (units)
4. the result is 2*x+2 (units)

Answer 18

A lot depends on how detailed you want to get - but additional 'buffer' time should be based on a risk assessment - at a task level, where you put in various buffer times for: High Risk: 50% to 100% Medium Risk: 25% to 50% Low Risk: 10% to 25% (all dependent on prior project experience).

Risk areas include:

• est. of requirement coverage (#1 risk area is missing components at the design and requirement levels)
• knowledge of technology being used
• knowledge/confidence in your resources
• external factors such as other projects impacting yours, resource changes, etc.

So, for a given task (or group of tasks) that cover component A, initial est. is 5 days and it's considered a high risk based on requirements coverage - you could add between 50% to 100%

Answer 19

I dont inflate my estimates I pad them!

Answer 20

I like the "double it" policy. However, at the very least increase it by 30%. This was once told by us by a Sr. Manager at my last IBank.

Answer 21

Two weeks.

Industry standard: every request will take two weeks. Some will be longer, some will be shorter, everything averages out in the end.

Answer 22

We have to, because our idiot manager always reduces them without any justification whatever. Of course, as soon as he realizes we do this, we're stuck in an arms race...

I fully expect to be the first person to submit a two-year estimate to change the wording of a dialog.

sigh.

Answer 23

<sneaky>
Instead of inflating your project's estimate, inflate each task individually. It's harder for your superiors to challenge your estimates this way, because who's going to argue with you over minutes.
</sneaky>

But seriously, through using EBS I found that people are usually much better at estimating small tasks than large ones. If you estimate your project at 4 months, it could very well be 7 month before it's done; or it might not. If your estimate of a task is 35 minutes, on the other hand, it's usually about right.

FogBugz's EBS system shows you a graph of your estimation history, and from my experience (looking at other people's graphs as well) people are indeed much better at estimating short tasks. So my suggestion is to switch from doing voodoo multiplication of your projects as totals, and start breaking them down upfront into lots of very small tasks that you're much better at estimating.

Then multiply the whole thing by 3.14.

Answer 24

Six weeks.

Industry standard: every request will take six weeks. Some will be longer, some will be shorter, everything averages out in the end.

Also, if you wait long enough, it no longer becomes an issue. I can't tell you how many times I've gone through that firedrill only to have the project/feature cut.

Answer 25

I'll be able to answer this in 3-6 weeks.

Answer 26

If you have to double or inflate your estimates in order for them to work out close to reality then your original estimate was clearly wrong or incomplete. Estimates need to include all factors the task may encounter. Adding extra time for no valid reason is just covering your a**, there should be a reason behind the full amount, not just add X to be safe. If you know there will be redesign and tweaks, then factor those in, same for meetings, testing, bug fixes, etc.

A proper estimate should match atcuals or be close, otherwise the estimate was incorrect.

The goal is to have actuals be as close to the estimate as possible, coming in well under is just as bad as going over in the estimating game IMHO.

Answer 27

The Scotty Rule:

• make your best guess
• round up to the nearest whole number
• double that quadruple that (thanks Adam!)
• increase to the next higher unit of measure

Example:

• you think it will take 3.5 hours
• round that to 4 hours
• quadruple that to 16 hours
• shift it up to 16 days

Ta-daa! You're a miracle worker when you get it done in less than 8 days.

Answer 28

As a lot said, it's a delicate balance between experience and risk.

1. Always start by breaking down the project in manageable pieces, in fact, in pieces you can easily imagine yourself starting and finishing in the same day

2. When you don't know how to do something (like when it's the first time) the risk goes up

3. When your risk goes up, that's where you start with your best guess, then double it to cover some of the unexpected, but remember, you are doing that on a small piece of the project, not the whole project itself

4. The risk goes up also when there's a factor you don't control, like the quality of an input or that library that seems it can do everything you want but that you never tested

5. Of course, when you gain experience on a specific task (like connecting your models to the database), the risk goes down

6. Sum everything up to get your subtotal...

7. Then, on the whole project, always add about another 20-30% (that number will change depending on your company) for all the answers/documents/okays you will be waiting for, meetings we are always forgetting, the changes of idea during the project and so on... that's what we call the human/political factor

8. And again add another 30-40% that accounts for tests and corrections that goes out of the tests you usually do yourself... such as when you'll first show it to your boss or to the customer

Of course, if you look at all this, it ends up that you can simplify it with the magical "double it" formulae but the difference is that you'll be able to know what you can squeeze in a tight deadline, what you can commit to, what are the dangerous tasks, how to build your schedule with the important milestones and so on.

I'm pretty sure that if you note the time spent on each pure "coding" task and compare it to your estimations in relation to its riskiness, you won't be so far off. The thing is, it's not easy to think of all the small pieces ahead and be realistic (versus optimistic) on what you can do without any hurdle.

Answer 29

I take my worst case scenario, double it, and it's still not enough.

Answer 30

I say when I can get it done. I make sure that change requests are followed-up with a new estimation and not the "Yes, I can do that." without mentioning it will take more time. The person requesting the change will not assume it will take longer.

Answer 31

I don't 'inflate' so much as work out my most likely worst-case scenario. Depending on the complexity of the project, I may pad more just to account for unforseen circumstances.

Since my projects don't often reach 'worst-case scenario' status, I'm usually done before the estimated time, but close enough for estimatory purposes. Given the choice between being done too early or too late, I'll go for early every time.

Answer 32

Any organization that asks its programmers to estimate time for coarse-grained features is fundamentally broken.

Steps to unbreak:

1. Hire technical program managers. Developers can double as these folks if needed.
2. Put any feature request, change request, or bug into a database immediately when it comes in. (My org uses Trac, which doesn't completely suck.)
3. Have your PMs break those requests into steps that each take a week or less.
4. At a weekly meeting, your PMs decide which tickets they want done that week (possibly with input from marketing, etc.). They assign those tickets to developers.
5. Developers finish as many of their assigned tickets as possible. And/or, they argue with the PMs about tasks they think are longer than a week in duration. Tickets are adjusted, split, reassigned, etc., as necessary.
6. Code gets written and checked in every week. QA always has something to do. The highest priority changes get done first. Marketing knows exactly what's coming down the pipe, and when. And ultimately:
7. Your company falls on the right side of the 20% success rate for software projects.

It's not rocket science. The key is step 3. If marketing wants something that seems complicated, your PMs (with developer input) figure out what the first step is that will take less than a week. If the PMs are not technical, all is lost.

Drawbacks to this approach:

1. When marketing asks, "how long will it take to get [X]?", they don't get an estimate. But we all know, and so do they, that the estimates they got before were pure fiction. At least now they can see proof, every week, that [X] is being worked on.
2. We, as developers, have fewer options for what we work on each week. This is indubitably true. Two points, though: first, good teams involve the developers in the decisions about what tickets will be assigned. Second, IMO, this actually makes my life better.

Nothing is as disheartening as realizing at the 1-month mark that the 2-month estimate I gave is hopelessly inadequate, but can't be changed, because it's already in the official marketing literature. Either I piss off the higher-ups by changing my estimate, risking a bad review and/or missing my bonus, or I do a lot of unpaid overtime. I've realized that a lot of overtime is not the mark of a bad developer, or the mark of a "passionate" one - it's the product of a toxic culture.

And yeah, a lot of this stuff is covered under (variously) XP, "agile," SCRUM, etc., but it's not really that complicated. You don't need a book or a consultant to do it. You just need the corporate will.

Answer 33

Of course, you'd have be to an idiot not to add 25-50%

The problem is when the idiot next to you keeps coming up with estimates which are 25-50% lower than yours and the PM thinks you are stupid/slow/swinging it.

(Has anyone else noticed project managers never seem to compare estimates with actuals?)

Answer 34

Kirk : Mr. Scott, have you always multiplied your repair estimates by a factor of four?

Scotty : Certainly, sir. How else can I keep my reputation as a miracle worker?

Answer 35

My general estimation is guess * 2.5 + 1 week.

Answer 36

Death March has some great writing about this.

My favorite is when he says that one of the games we play in a company is that Engineers double the estimate, and then Management and Marketing cut it in half - woe befalls the Engineer who wasn't told he was supposed to double his estimate. <grin/>

The other game he refers to is when a manager makes you keep revising your estimates until you come to the date that they wanted all along. I actually don't have a problem with this one, as long as the Engineer is allowed to fiddle with the scope, implementation details, which 3rd Party packages they use, and maybe even the budget... As long as Marketing / Management / Engineering all ends up on the same page, and the Engineer wasn't forced to artificially bring in the estimate.

[Edit] Oh, I almost forgot - there's another classic method: *2,+1. First, multiply your estimate by 2, second increase your units of measure by one. If your honest estimate is 3 weeks, instead make it 6 months. <evil-grin/>

Answer 37

Don't forget you (an engineer) actually estimate in ideal hours (scrum term).

While management work in real hours.

The difference being that ideal hours are time without interuption (with a 30 minute warm up after each interuption). Ideal hours don't include time in meetings, time for lunch or normal chit chat etc.

Take all these into consideration and ideal hours will tend towards real hours.

Example: Estimated time 40 hours (ideal) Management will assume that is 1 week real time.

If you convert that 40 hours to real time:

• Assume one meeting per day (duration 1 hour)
• one break for lunch per day (1 hour)
• plus 20% overhead for chit chat bathroom breaks getting coffie etc.

8 hour day is now 5 hours work time (8 - meeting - lunch - warm up).
Times 80% effeciency = 4 hours ideal time per day.

This your 40 hour ideal will take 80 hours real time to finish.

Answer 38

I avoid time estimates for a project at all costs. Instead I prefer to predict time to the first milestone and map out milestones towards completion, periodically reviewing pending milestones as I go.

Exceptions: When the code is essentially complete and simply needs to be modified for the milestone. When the project is trivial or largely identical to a prior project. When there is a complete and accurate specification (such as in the case of an application platform conversion).

If a customer or manager is insistent upon a firm target date, then I'll insist on a complete specification set in stone. Or I find another manager or customer. If none of that is an option, I'll pull a date out of the air and let them know it is highly inaccurate and will likely be missed but will refined as milestones are complete.

Types of time estimation tricks and approaches all vary from type of project to type of project which is why estimation remains a fuzzy art.

Answer 39

I take the opposite approach to what seems to be the most common attitude, I try to make my estimates as accurate as I can and then make sure that the project manager knows that I don't pad my estimates. It's then up to them to apply any random factor of 2 or what ever they feel comfortable with.

When I'm giving estimates I also like to give some sort of indication of how through the estimate is. Some sort value ranging from "I've just plunked that number out of my ass" to "I've spent the last week detailing and listing all of the tasks, prototyping any complex or unknown integration and the estimate is a statement of fact" (not a common one that :)

This has mainly come from a couple of projects where it seems that everyone in the management chain has added there own little fiddle factor to the estimate such that the initial project plan is about 3 times longer than it should be. What seems to follow such things is round of random horse trading that chops the project time down without any real reference to anything other than office politics.

I guess it is a case of how much you trust the person your giving the estimate to, I sincerely believe that you have to be able to trust and be 100% honest with your project/product manager and be able to give them estimates that you honestly believe are truthful. The flip side to this is they have to be reasonable and when you over shoot your estimates talk about it and try to improve your estimating and not just chew you a new one.

Answer 40

I usually take about 250% of the initial timespan I think of within the first ten minutes of evaluating the project. The first 100% is for the things I know can be done and fast, the next 100% is extra because of unforeseen events, and the last extra 50% is 'communication with other people'.

Seems to work fine for me.

Answer 41

1. Calculate an estimate you think is as accurate as possible.
2. Double it.
3. Quote the result, but add "plus or minus 25%".

For example, if you think it should take 6 workdays, predict "12 workdays, plus or minus 3 workdays".

Answer 42

I remember on the start of this current project, the then project manager gave an estimate just straight off the cuff of 6 WEEKS!

My eye's just bulged out of their sockets! Knowing there were still heaps of areas which we didn't even know how to tackle. This guy was senior because he had more 'experience'

Needless to say 6 weeks later the specification was still being written and virtually no code had been even considered.

Eventually we downsized the team (To only me!) and actual progress was finally made. I learnt a long time ago while being a contract draftsman how to estimate accurately.

There are two chief skills involved.

FIRSTLY Practice estimating. Nothing beats actually having a go at estimating various projects - even if you are not the project manager, it doesn't matter if you get it wrong or not - but keep an internal estimation of every project you do (well it should matter if you ARE the project manager)

SECONDLY Most project blowouts are due to project dependancies, Identifying these upfront is critical to knowing which factors are able to derail the project if they slip.

Answer 43

I add 50%. However, that can move to double or more if I've worked with the client before and I know they like to make changes toward the end. I try to anticipate the unknown as I can...sometimes I succeed, sometimes fail.

Answer 44

My estimates are usually very accurate (comes from 20 years of experience) but I still usually inflate mine a little; it's always better to under-promise and over-deliver when it comes to bonus time :-)

Still, it should make very little difference what you do with your estimates if your project manager is worth anything (some aren't worth the oxygen they consume but I believe they're in a minority).

They will be tracking your estimates against your actuals and using that information to adjust your next set of estimates before entering that into the project plan. That will let them build up an accurate picture of how well you estimate certain tasks (I always base them on type such as UI, DBMS, middleware, etc and size/complexity).

Then, if they see that you continuously underestimate UI tasks, they'll know to bump them up in the next iteration. If they can see that you're feather-bedding some tasks, they'll know to reduce your estimate. This has the advantage of automatically adjusting over time.

Seriously, some people think PMs sit around on their ars*s (or ass*s in the good ol' USofA) all day doing nothing, but there is at least a modicum of engineering and science behind the job. I know, I used to be one before I returned to my passion of code-cutting.

Answer 45

I never just double it. Usually a design/idea/change is presented on a post it note I usually start with out with an estimate of about year and the more refined the post it notes get I get the better my estimate gets.

Even with this I know that when I finish my implementation I'm only half done. That's usually well within the original year estimate so there's plenty of time for the post it writer to flush out any design problems.

Answer 46

If you're a Consulting Firm, you really need to be thoughtful about padding your estimates too much. You need to make profit, right? You can't do that if you're shielding your resources from taking on their next assignment sooner. Also, consider what kind of project you're going to undertake. Will you be able to do a T&M with the Customer? If not, and you're forced to provide a fixed bid, also include a fixed duration and share the risk with the client. I can't tell you how many colleagues I see that screwed on thewes kinds of topics on this discussion. As a PM, you've got to step up and a) provide a small, reasonable padding to assure the delivery date can be met, b) negotiate and share the risk invovled in a fixed bid project by getting good language in the SOW to protect you, and c) you're trying to win the work, right??? Act like, and assure your A-team gets its hands on the estimates during the planning stage to remain competitive.

WPF and Silverlight are rather new, but we're quickly getting competitors underbidding us.

Slightly off topic, but help the Customer realize the intensity of your team when negotiaitng the project with Sales. A good PM can help win respect and trust from a new Customer.

There's really little difference when talking about an internally funded project. Because of the nature of the beast and condemning lifecycle and req's from many of these types of projects, they need stronger Project Management than some high risk, short duration external projects.

Lastly, you must get buy-in from the resources that are going to perform the work. A Team Lead should bless the estimates and be able to tell if they're high or low. You've got to be able to make ROI on every project, so there's times when you may need to pad estimates more than desired. But truly if the work is small, and you're left throwing a B or a C resource team at the project, leave the opportunity on the table if the bid is too high. Unless it makes significant biz sense, avoid taking the gig if you truly do not have resources to pull it off. In this economy, that's not always an option.

Answer 47

I always double my estimates, for the following reasons:

1) Buffer for Murphy's Law. Something's always gonna go wrong somewhere that you can't account for.

2) Underestimation. Programmers always think things are easy to do. "Oh yeah, it'll take just a few days."

3) Bargaining space. Upper Management always thinks that schedules can be shortened. "Just make the developers work harder!" This allows you to give them what they want. Of course, overuse of this (more than once) will train them to assume you're always overestimating.

Note: It's always best to put buffer at the end of the project schedule, and not for each task. And never tell developers that the buffer exists, otherwise Parkinson's Law (Work expands so as to fill the time available for its completion) will take effect instead. Sometimes I do tell Upper Management that the buffer exists, but obviously I don't give them reason #3 as justification. This, of course depends on how much your boss trusts you to be truthful.

Answer 48

Bearing in mind that most developers dont factor in much test time, nor much bug fix time, nor the admin overhead (email, coffee, meetings ..etc) some groups only schedule 20 hours a week and/or multiply by at least 2.5

Answer 49

"Everything takes longer than it does"

Answer 50

Yes, I inflate them. But not by enough.

Answer 51

I've never thought that estimates were inaccurate because a programmer was not capable of estimating how long it takes to write code, but because they estimate how long it takes to write the code ONLY. Meetings, client response time, testing, client changes, revisions to business rules and the like don't get estimated at all.

When those items are accounted for in the beginning, and the project is estimated at the task level, not "Oh, I think this will take... 7 weeks!" Then estimates are generally accurate.

So if I pad, it's because I happen to know that these items were not accounted for, or that these items were not calculated appropriately.

Answer 52

Under-promise, over-deliver.