When to decide?

I have recently experienced several occasions where people want to decide things as early as possible in a project. This seems to be based on previous experiences that this was difficult in the last project and we want to eliminate things to worry about late in the project since there will be new things to worry about then anyway. So why not solve the major problems you are aware about anyway?

I think this kind of thinking is detrimental for the success of the project, especially if the decision influences the architecture (Grady Booch said something like "the architectural decisions are those costly to change").
If one looks at the reason the problems came up in the first place it is usually things like the implications (especially technical) of the decisions was not fully understood, the requirements were not suitable, or my personal nightmare that my team will not suffer any consequences whatever the outcome so why not decide this now...

If one has superficial understanding of the consequences or if the requirements are unstable it is a better strategy to postpone the decision as late as possible, and also delegate it to those who are most affected/concerned. But this means you and your organisation is comfortable with living with uncertainty. Which may be very difficult depending on the culture or the organisation. For example if all of your project revolves around a stage-gate process (very common in the automotive industry) it really does not fly well to say "let's postpone this decision for another 6 months and make progress with what we can".

It may sound I ampreaching the agility gospel, but that is not the case. I have full understanding that once you have made an architectural decision you don't want to change it. I just want to argue for the heuristic that you should not decide something because you can, postpone it to when you have make it.
And as a consequence I really dislike when you have to decide things just to feed the process, especially if the process is very slow to change.