Yes, all the time. Being pessimistic helps, but you also need good - and more importantly, self-aware - engineers, and a senior management structure that's willing to work with you.<p>The keys, basically, are realistic estimates and a willingness to de-scope. If you're willing to launch something with a few bugs and some small features missing, and to improve them in subsequent releases, you can hit any reasonably realistic launch target.<p>In the days of shrink-wrapped software, those bugs and missing features might have been unacceptable, but in a world of web apps and of app stores with automatic updates, iterative follow up releases for polish and improvements and even to incorporate user feedback should be a routine part of any software process.
I had a startup that was focused on fixing project failure through better requirements management. Page four of our slide deck was the fact that approximately 84% of IT projects fail (where "fail" is over budget, late, or failed to meet the requirements). The newest version of the report has actually improved a bit on those numbers (~30% success now) but it's still terrible.<p>There's quite a decent blog post about it here <a href="https://speedandfunction.com/look-25-years-software-projects-can-learn/" rel="nofollow">https://speedandfunction.com/look-25-years-software-projects...</a>
I have been on 3 - 4 "large" projects. My definition of large = $100+M budget with 400+ ppl working.<p>3 of the 4 projects failed altogether and were cancelled after about a year for blowing both budget and timeline.<p>The large project that did not "fail" was deemed too strategic and the business simply decided to invest more and keep going until done. Once management came to terms with the 3+ year timeline, things got a lot more sane.
There was one project which I had worked on , the project plan was around 6 months and it was executed on schedule till the very last day. It was not a complex project though.<p>Migration of a whole bunch of sites to new server , OS + some new developments etc,with a whole lot of users across several countries. It was the first time I actually saw someone prepare a plan for ~ 6 months and made it happen too.
Often.<p>Agile true works. Identify the core, build it quick. No more than one month. Release and deploy to production. Sprint! Release every 1 week or 2 weeks on production.<p>This is my approach to delivering software.