4 ms·

220% also works fine if each one of the projects is "practically unique" to you / the team... this happens >50% of the time in the real world, imo, because some

by nnq 8y ago

220% also works fine if each one of the projects is "practically unique" to you / the team... this happens >50% of the time in the real world, imo, because some fields have very little transferable skills/experience from project to project... a large percent of stuff is genuinely new every time and never repeats even if it's "basically the same thing as that other project"! (Or team composition changes.) Problem is the fact that you can only justify with a straight-face 45% (100%/220%) of the estimate you give to the client... Then you need to get clever at "bluffing" your way at "inventing" another extra +35% of work that you can't imagine/explain, but you know for sure that will come out of the blue - you know there's this extra 35% work needed for sure, you just have no idea what this work will be. Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. There's two ways to see the same math: (1) 45% + 35% + 20% = 100% (2) 100% + 100% + 20% = 220% The world would be a much better place if clients / managers / project owners etc. would just accept that 55% of time & cost for software dev is unknown-unknowns type of unexplainable/unimaginable-at-project-start-stage-work. That's just how it is! If the problem was really clearly defined and understood, there would likely already be an off-the-shelf software solution for it that could be used instead of paying developers to build custom software! If we could just be honest with people and show them formula (2) instead of a make-up-ladden version of (1). But people don't, so we get to play the damn elegant-bullshitting game over and over again...

Roark66 8y ago
>Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. This is how I always have done it across multiple jobs and I always called that extra contingency. Depending on the project I sometimes had to ask for over 50% of the total as contingency. If anyone queried it I would explain that it is very likely we'll need it based on my experience of many other projects. Then the client would either accept it as is, or they would want to split the proposal into "what we will definitely pay for" and "what we will pay for only when it is actually needed" which is also fine for both sides if proper progress reporting has been agreed in advance. Someone could think that no client would agree to such a contract as it would open them to be taken advantage of by an unscrupulous supplier, but at the end of the day what matters in business is trust. If a client doesn't trust the supplier they shouldn't hire them. And in all my previous projects I never met an engineer or developer that would deliberately use up the contingency time when it is not needed as everyone knows the availability of this extra time might come very important towards the end of the project.
- thatoneuser 8y ago
  That's a smart way to do it. I used to put in ranges (basically contingency) of rate but I found myself consistently hitting a similar % of the higher estimate and just started quoting the higher estimate with the expectation that I'm not a God and there may be unknown factors which could add in more cost. Usually people are happy as you say if there's trust and you show progress.

by nnq 8y ago

Roark66 8y ago

>Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. This is how I always have done it across multiple jobs and I always called that extra contingency. Depending on the project I sometimes had to ask for over 50% of the total as contingency. If anyone queried it I would explain that it is very likely we'll need it based on my experience of many other projects. Then the client would either accept it as is, or they would want to split the proposal into "what we will definitely pay for" and "what we will pay for only when it is actually needed" which is also fine for both sides if proper progress reporting has been agreed in advance. Someone could think that no client would agree to such a contract as it would open them to be taken advantage of by an unscrupulous supplier, but at the end of the day what matters in business is trust. If a client doesn't trust the supplier they shouldn't hire them. And in all my previous projects I never met an engineer or developer that would deliberately use up the contingency time when it is not needed as everyone knows the availability of this extra time might come very important towards the end of the project.

thatoneuser 8y ago
That's a smart way to do it. I used to put in ranges (basically contingency) of rate but I found myself consistently hitting a similar % of the higher estimate and just started quoting the higher estimate with the expectation that I'm not a God and there may be unknown factors which could add in more cost. Usually people are happy as you say if there's trust and you show progress.