I am an OpenEdge (aka Progress) developer that loves clean code and good looking applications that are easy to use. My main pet project is the Progress DataDigger
If my manager wants an estimation from me, I think of how long I think it will take. The outcome gets multiplied bij pi (like you mentioned) and that estimation goes to my manager. In most of the cases, this turns out not to be that far off. But reality forces me to admit that there is also something like Parkinsons law so my multiplier of pi might be too high.
The very reason I have a multiplier is - I think - an indication that the whole principle is wrong. If I have to multiply with a factor, it shows that I cannot safely estimate. It has become guesstimating.
Enter the management triangle:
In short: there is time, budget and quality. Any of these can be controlled by the project owner, but you can only pick two; the third one follows from the two you pick. The agile movement uses just this. It fixates time and budget, so quality follows from that. With 'quality' you can also read 'features'. Imo, this leads to better projects. The focus in agile approaches is to always have working software, so you just iterate until the project owner thinks it is good enough.
In general, software is way too complex to fully estimate in advance, so your best bet might be to accept that and use it as a basis for your planning.
helping robots conquer the earth and trying not to increase entropy using Python, Data Engineering and Machine Learning
Check out my blog - http://luminousmen.com
If my manager wants an estimation from me, I think of how long I think it will take. The outcome gets multiplied bij pi (like you mentioned) and that estimation goes to my manager. In most of the cases, this turns out not to be that far off. But reality forces me to admit that there is also something like Parkinsons law so my multiplier of pi might be too high.
The very reason I have a multiplier is - I think - an indication that the whole principle is wrong. If I have to multiply with a factor, it shows that I cannot safely estimate. It has become guesstimating.
Enter the management triangle:
In short: there is time, budget and quality. Any of these can be controlled by the project owner, but you can only pick two; the third one follows from the two you pick. The agile movement uses just this. It fixates time and budget, so quality follows from that. With 'quality' you can also read 'features'. Imo, this leads to better projects. The focus in agile approaches is to always have working software, so you just iterate until the project owner thinks it is good enough.
In general, software is way too complex to fully estimate in advance, so your best bet might be to accept that and use it as a basis for your planning.
It's a good point, thank you for your comment!