I have now a good process for estimating development work for projects, I think how much time it would take me to do it considering the worst case scenario, and then I double that number. For each of my team members I have another ratio (higher or even lower) but the idea is the same.
My problem is the fixes phase, it is very hard to tell up front how much time to reserve for issue resolving as it depends on many parameters (complexity of the project, staff skill level, management and design quality, QA quality etc)
I am still to decide on a percentage from the project pure development estimation that I should always add for the issue fixes (Just the fixes phase untill "go live" / "production" / "next release" etc)
Is there a methodology that defines an actual golden ratio number? does anyone have one? 20%? 50%?
On a traditional waterfall style project, we found a good rule of thumb was 20/20/20/40 - 20 HLD, 20 DD, 20 CCUT, 40 integration and test. I've always found that to be useful in that it works both for initial estimates and for a checkpoint when you are part way into the cycle.
From an ongoing post-delivery maintenance, I don't have as good a ratio. Most projects I know, don't even try, they just budget some number of support hours, and figure some will be bugfix, and some will be user handholding.
Addition - realized I ought to clarify my acronyms:
HLD = High Level Design DD = Detailed Design CCUT = Code, Compile, Unit Test
I'm pulling from traditional waterfall concepts here as that's where I've had access to the most metrics. So these assume that you'll (more or less) have to do HLD before DD, DD before CCUT and so forth. Practical experience shows they can blend more than a little, but if you have HLD and CCUT happening at the same time, you have some real risks afoot.