If you split one big project into five smaller projects,
You will need someone to select the split points and manage the communications between the sub-projects. And when each is done, you'll have to integrate them and test the assembly. Not that this is necessarily bad. But that mangement layer adds complexity and overhead. Agile might work well in an environment where the sub-projects are just teams sitting in adjacent cubicles, working in the same organization. Where interface problems can be solved by grabbing a few people, finding a conference room with a white board and working things out. But not so well if the inter-project communications involves customer/vendor contractual negotiations. And management starts to get it's panties in a bunch over change orders.
In my experience, management is often selected based on the Dilbert Principle. Not the sort of people you want sitting at the nexus of the critical communications path between groups trying to get actual work done. Not to be totally down on Agile, it does formalize the inter-group communications, giving the PHBs well defined documents to rubber stamp and otherwise restricting their ability to invent new processes on the fly.