[kilburn]

> In other words, the argument is "competing priorities in a large-scale project make it more likely to fail, because stakeholders can't figure out which ones to do first."

This is a misinterpretation of the article's claim. The article very explicitly begins by saying that the best recipee to increase a project's chances to success is to:

> 1. Start as simple as possible;

> 2. Seek out problems and iterate;

The priority part reads to me as a way to determine which features are critical (and hence part of the as simple as possible set) and which ones are not (and hence you should not build "yet"). The underlying vibe being that these other features should probably never get implemented because once the critical ones get built and the software is put to use you will actually find other critical fearures that solve actual problems found through usage.

That is, only when you find that one of the initially non-critical features has become a hindrance for users actually using your software you should seek to implement it.

I really think this would be a better way to build software, just as much as I think that you will have a very very hard time getting any management on board with it...