One greenfield/rewrite project I saw had a large team, which previously was maintaining and evolving a legacy system that the new system was to replace. (I was

One greenfield/rewrite project I saw had a large team, which previously was maintaining and evolving a legacy system that the new system was to replace. (I wasn't from that team, so more on the sidelines.) The new system was to support new requirements, have fewer legacy constraints, and benefit from using more off-the-shelf libraries and frameworks. It was more complex than it was bulky (i.e., cross-domain designs to nail, not tons of rote coding to churn). They had an aggressive timeline. One risk you might imagine is Second System Syndrome. And there was some of that, more with everyone wanting to jam in every feature, and maybe also Analysis Paralysis on some parts the architecture. But the biggest problem was that, collectively, that particular team just couldn't build a new system that would come together in a sufficiently timely fashion. At least part of the problem was that management definitely dropped some balls they couldn't afford to. Had the engineers been organized better, and used more appropriate process, I don't know whether they could've risen to the challenge.