If I were to say that you should run the same project with two separate teams in parallel to insure against project failure, you would probably call me crazy. Pay twice for one thing? Yeah, right. Even when I remind you that 60% of software projects fail, you would still assume that doesn't justify the pay twice approach. (That's why we do agile, right? ... to avoid that failure!)
BUT, what if that failure normally happened in the first 20% of the timeline? Would that change your mind?
Peter Stevens wrote a great post about using competitive sprints to select a vendor. It's a pretty interesting read. It even suggests that just because a parallel team "loses" doesn't mean that parts of their work won't get incorporated into the winner. Check it out.
This is an agile focused topic, but I think you would very easily apply it to non-agile but iterative work of any type. I think I've even heard stories that Toyota or Mazda uses this process to create new car models. Different teams create concept cars and as they show with focus groups and auto shows, certain teams get disbanded and removed and the winner slowly emerges. Now that is a good way to bring a car to market that will have demand behind it.
Instead, we normally put all our eggs in one basket.