システム開発プロジェクトの分類

すべてのシステム開発プロジェクトを同じ視点・同じ戦略で語るのには無理があると思う。
分類した上で各分類に対して適切な方法を議論できるのではと思っています。
もしかしたら分類できないのかもしれませんが。
＃各プロジェクトによってだったら悲しい。

顧客の範囲

変な言葉を作りましたが、これは顧客側のステークホルダーが何種類いるのかという意味です。1種類であれば（1種類はまれで、現場とスポンサーといった2種類いるのが普通ですが）、個別最適をすればよいので機能要求で対立することは少ない。
そのため、フィードバックを重視した開発戦略をとるのが一番よいと思われます。
機能単位ごとに顧客にフィードバックもらっても大きな混乱がおこらないので顧客にとって価値のある順につくればよいのかと。
複数のステークホルダーがいる場合は、多くの場合「要求の対立」が起こるのでその調整を最初にやっておかないといけません。もし、この手順を踏まないでフィードバックを重視するとフィードバック毎に大きな変更が起こりアーキテクチャそのものも変わらず得ない場合がありプロジェクトが混乱する可能性があります。

規模

ある程度以上の規模があるとプロジェクトの参加メンバーが増えます。
もちろん、「困難は分割して解決せよ」という考え方を用いて組織を分割することで対応しますがそれでも階層が深くなると分割すればよいということでもなくなっていきます。
その規模の大きさはプロジェクトを実施する組織によって異なると考えられます。

プロジェクト組織の配置

プロジェクトを実施する組織の場所をどう確保するのかというのが一つの問題になります。プロジェクト全員を同じ場所に集めることができるか否かというのがプロジェクトの方法が変わることになります。
コストの問題で「オフショア」*1といういこともあるわけです。
その場合の開発の進め方がかわるでしょう。

リスク

プロジェクトが持っているリスクによっても大きく変わると考えられます。
上記の問題も分類していくと最後はリスクに行き着くわけですが。

*1:いいか悪いかは別の問題