Requirements, infrastructure components, platform systems and promises from external vendors that "it'll totally be ready by the time you launch".
This is all things I've seen in the last month (yeah I'm not joining any more greenfield projects within organizations - if you think you're going to rebuild it from scratch and fix all the problems, you have no idea what went wrong in the first place).
It might be even the idea that (without an effort that matches or exceeds the implementation itself), you can "get the requirements right", i.e. that there is a point in time where the requirements are complete, fully understood and thoroughly specified.
Given the enormous scope of some of these projects I wonder if a prototype phase would help. Humans seem to have a hard time with conceptualizing and a slow, barely/non working and unscalable prototype might be worth the added cost/time. If it’s part of the requirement gathering process with explicit expectations set that it’s a prototype would it facilitate better requirements input? Naturally you’d have some people making assumptions about its fitness as a final product or MVP but (if a UI is involved) giant bright warning banners plastered all over might help with that.
You're right, it's hard to correctly spec out a software project. You can't build a house without the plans.
Another big factor is testing/QA. If your customer service department isn't going to throughly test your new program, and nobody holds them accountable, who gets blamed on launch day when it doesn't work right? IT!
You can build a simple house without formal plans, most especially if architect, builder, and owner/occupant are the same.
Divide roles, or increase complexity of the project, or its relationships with the surrounding infrastructure, and planning or standardisation requirements escalate quickly.
Yes, you can build a simple house like that. But what if halfway through the construction, the client says they want the bathroom on the other side of the house? You'd have to redo (e.g.) all the plumbing from the ground up, location of the heating system, walls, doors, perhaps even staircases ... etc. etc.
Note that amongst my qualifiers was unity of client and builder-architect.
You'll find plenty of examples of people on DIY or lone-inventor projects saying "we tried X, it didn't work, so we did Y instead. That's the unity-actor case of your hypothetical.
Dividing executive-agent roles is a complexity dimension.
Dividing executive (decision), design, expert (engineering), sourcing, external approval, interface, and labour/crafstmaan roles are multiple additional complexitty dimensions. And this doesn't even include the technical dimensions of the project and its infrastructure interfaces / interconnects.
Complexity is interaction between components and entities.
Yeah but behind your "as much as possible" statement hides the whole softwar engineering profession. Getting the requirements right sometimes can paralize a team, making it loose "capabilities" or momentum or even having attrition impact. There's no single PM methodology solution to avoid having the deal with the tradeoffs associated with the agile vs. waterfall dichotomy.
Behind any popular or profitable succesfull software project there are sometimes as much "PMing" practices as there are coders.
Many managers seem to think that they can easily change the requirements in the middle of the project.