Why internal IT projects fail – relaoded

Lately I’ve blogged about internal IT projects that do fail and one of the main reasons: lack of Product Owner (Why big projects fail in corporate IT).
Today let me emphasize another major reason: often the team who’s in charge of a project … will leave (I’d say run away as fast as light) as soon as the project is complete. And usually ‘complete’ means ‘when we are exhausted of fighting with the supplier for bugs, change requests and new features’. And all this means that the project is not complete at all. And in any case we know it will evolve.
What is stimulating the project team, in such a context, to work effectively? Work for simplicity? Work to establish a system that will grow up or change in the future weeks / months / years? Are they measured in any way on these goals? Or are they measured on ‘close this fuxxing project quickly that we have already spent all the money they gave us’?
PierG