会社によってそう呼ばれる基準はまちまちですが、
大規模の方がリスクが高くなるのは当然ですね。
「大規模プロジェクトではどうするか」を考えるより、「大規模にしないためにはどうするか」を考えよう - kなんとかの日記
ソースコードの規模もそうですが、
プロジェクトに関わる人員の数にもよると思います。
私の経験上ですが、1人で10人の作業を見ることはできません。
せいぜい5人って所です。
それくらいなら誰が何をしているかを把握することができますし
困っていそうならフォローすることも可能です。
あまりにも管理する対象が多すぎると、誰が何をやっているか把握できず
無駄なことをやっていたり、ともすればサボっていても気づかない状況になります。
で、1人を頂点とした6人体制でグループを作り
グループの数を増やしたり、複数のグループを管理する人を増やしたりして
プロジェクトの規模を大きくしていきます。
それでも、グループ間の情報共有がうまくいかないと回らなくなるので
仕様(変更)を小さくする努力も必要です。
5%しか起こらないケースに対して一生懸命作りこんでも、
何人ありがたがるっちゅうねん!って話です。
実装者が言語や技術的なことを駆使して(無謀だと思われる)仕様通りのものを作るより
要件を満たす為に、という観点で設計しなければならないんだと思います。
(技術的にチープでもユースケースが満たせればそれでいいじゃないですか)
やっぱりプロジェクトを失敗させない為には、大規模にしないことだと思います。
半年で(仕様を知るところから始めて)社内システムをリプレースなんてありえない・・・。
大規模プロジェクトは数字的にもかっこいいので、ギャンブル要素満載ですね。
成功しても失敗しても人が流れていくのは世の常。