> "Over 90% of enterprise IT projects are delivered late." Due to piss poor project managers and lack of business requirements and/or realistic deadlines.
For example, let's say a team is given 4 projects. They provide rough effort estimates and schedule those projects on the calendar, with normal buffer for support issues, changes, etc. Then a new ultra-high-priority, life-of-the-company-at-stake project comes down from the CEO, and everything else gets pushed back by months.
So, are those original 4 projects technically late? By many studies' definitions, they would be categorized late.
Furthermore, does it matter if they are late? If you're late on 80% of your projects but deliver on time for 100% of your critical projects, is that so bad?
Not having the demo ready for the tradeshow is a real problem. Not having the compliance changes in by the deadline is a real problem. Not having the integration upgrade done before your partner turns off the old version is a real problem. And so on. Missing some date that was arbitrarily chosen, probably months or years ago, eh, that doesn't necessarily bother me.
I'm not arguing that it's good to be late. It's obviously better for projects to be delivered when expected to let businesses make projections, plan, etc. I'm just saying the real world is messy and full of tradeoffs. If you're constantly reacting to fires and unexpectedly missing deadlines, that's a sign that better project management is needed. However, if you're working with business stakeholders to reprioritize efforts and adapt to changing realities, that can be good in my opinion – even though externally it can appear that projects are "late".
Edit: To be clear, I'm not really agreeing or disagreeing with parent's comment on the source of lateness. I'm commenting on using stats like these as evidence that something is broken in software development.