赤字プロジェクト　工数増大が原因か、無駄が原因か

赤字プロジェクトは頭が痛い問題です。赤字の原因としては、「要件の詰めが甘く、ユーザとの認識違いから仕様変更が多発しそれに対応するため、結果として赤字になった」と言われます。

確かに、要件を全て確定することは、業務の要求もそれを実現するシステムが複雑化している現状では難しいことだと思います。ある程度のリスクがこの部分に内在していることは否めません。しかし、その一方で、要件定義、設計、さらにはプロジェクト管理の工数を、このリスクを減らすために有効に活用したかどうかに関してはあまり議論されません。かかってしまった工数に関してもう一度その使い方、特に100%は無理にしても出来る限り要件のぶれをなくすために打てる手を打ってきたかどうか、その反省は殆ど行われていません。

プロジェクトによって、事情は様々だと思いますが、特に大規模プロジェクトでは、目の前の設計や管理作業だけでなく、プロジェクト全体を見渡して、ある程度標準的な管理手法を逸脱しつつも、ユーザとの要件の詳細の詰めや確認作業を行う工数を別途確保しておくことで、後半になってのブレを多少でも少なくすることは可能だと思います。

もう一度赤字になったプロジェクトの、前半での資源の使い方を見直してみることも、今後同じ失敗を繰り返さないために重要なことだと思います。