Timeline for How to respond when you are asked for an estimate?
Current License: CC BY-SA 2.5
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 14, 2021 at 15:16 | comment | added | Kyralessa | @pcodex You mitigate unknown unknowns by building more slack into the project plan. | |
| Jan 14, 2021 at 13:11 | comment | added | pcodex | " is to simply tackle them head-on: Do those parts of the project first.." .....don't agree with you here. With unknown unknowns there would be nothing to tackle head-on and no there can be no definite risk mitigation plan since they are unknown in the first place. We can only be sure of what has occurred and an empirical approach is what would make sense in the situation I've outlined not your approach of trying to do an upfront estimation. | |
| Jan 14, 2021 at 5:42 | comment | added | Kyralessa | @pcodex In that case, those "unknown unknowns" are called risks, and they need to be mitigated. One way is to simply tackle them head-on: Do those parts of the project first. Another way is to do accurate estimates for the knowns, and much wider estimates for the unknowns, to reflect the uncertainty. A good project manager (and I don't claim to be trained as a project manager, mind you) will have tools to deal with this situation. | |
| Jan 14, 2021 at 2:20 | comment | added | pcodex | @Kyralessa this technique works if you have code or precedents which you can use to base the estimating on. With greenfield projects or features where even the technology being considered might be new there are several unknown unknowns and a different estimation technique may have to be followed from what you're suggesting | |
| Dec 3, 2017 at 18:22 | comment | added | King Friday | @Darius.V yah your comment actually makes sense, that's why you get those RFPs in which they want a detailed proposal sent back. I didn't really get it until this particular post detailed out for some reason. You end up screwing yourself over if you don't do the due diligence as the tldr; | |
| Dec 26, 2016 at 16:33 | comment | added | Kyralessa | @Darius.V, you make a good point. In this case the client's decisions were Yes or No to particular features, not an overall Yes or No to the entire project. This technique is certainly more challenging if doing the entire project or not depends on the overall estimate. On the other hand, if you're budgeting for six months for a project, but the project might actually take a year, would you rather find that out after six months, or after two or three? | |
| Nov 8, 2016 at 23:15 | history | wiki removed | Thomas Owens♦ | ||
| Jul 13, 2016 at 4:46 | comment | added | Darius.V | So if it is like 5 months project you should be estimating it for a month or more. Probably managers will not accept that :) | |
| Aug 7, 2015 at 7:40 | comment | added | NimChimpsky | @SergioAcosta the point is you use the analysis/estimation time to break down the task into smaller chunks. This is the best answer, imho. | |
| Mar 13, 2012 at 15:54 | history | made wiki | Post Made Community Wiki by Sardathrion - against SE abuse | ||
| Sep 29, 2010 at 13:32 | comment | added | Kyralessa | Yes, the same one. | |
| Sep 29, 2010 at 6:05 | comment | added | Sergio Acosta | That sounds like a very adequate technique. In fact, when you are making an estimate for your own company the estimate time is being paid as part of your salary also. I'm afraid, however, that the problem is that most organizations want estimates of much bigger tasks than the ones that can be expressed in .1 hour chunks. Thanks for your answer. (Are you the same Kyralessa from the joel on software boards?) | |
| Sep 29, 2010 at 4:29 | history | answered | Kyralessa | CC BY-SA 2.5 |