Producing accurate software development estimates is an art. These days they mostly seem to be wrong. How can we correct this pattern? Start by defining your project scope. Without that you are doomed to fail. Period. When the requirements change, so does the scope. You then need to estimate again.
Once you have the documented requirements, locate all the unknowns. Overestimate these items. Put together a list of deliverables to manage expectations. Remember to cost in security the first time around. There may also need to be time factored in for developer training.
This might be obvious, but you need a lot of time for testing. The current fix I am doing requires double the amount of time testing as it does coding. This should be the norm and not the exception. Get your developers to agree to the estimate, and more importantly the deadlines.
Add some slack in, no matter how well you think your estimate is. The estimation phase is the toughest one. Don't cave in to pressure to reduce the estimate. That will only lead to disaster.
Mastering Oracle PL/SQL - I received some newsletter from my company. It highlighted the book Mastering Oracle PL/SQL. I think this is targeted for me since I said my specialty is ...