. . . and then there's failure.

I think a lot of people believe projects longer than a year can succeed. I think they're defining project time and/or success differently from you, however:

1. They may be including time that is not actually spent on the project in project development time. For instance, if you plan a project out to some nontrivial degree, then set it aside for three months (maybe making improvements to the plan here and there in "free" time), and finally come back to it to start working on it in earnest, I wouldn't call the totality of those three months part of the project timeline for determining likely failure rate (though some minority percentage of that time should probably be counted -- a ratio that looks hopelessly heuristic from where I'm sitting).

2. Some people consider project completion synonymous with project success -- even if the end result manages to achieve the basic project plan requirements, but utterly fails to actually provide any value. A lot of long-term projects meet this description, declared successful by their developers and managers, though in terms of actual return on investment they are among the worst abject failures.

Even more interesting for me (who mostly hasn't had to deal with the situation described in my list item number 2, personally) is the fact that I think the rule-of-thumb limit on project length that can succeed is getting shorter. Further, I believe it will continue to get shorter at an increasingly rapid pace, at least for a while. As we develop new tools of automation that pertain to the development process itself, much of the scut-work will be obviated, and we can focus on the important stuff. This will reduce necessary project time, showing us the truth; it's not time that is the limiting factor, but project development complexity, which contributes to the time we spend (though some factors arising from time spent may come into play as well).