デスマーチを回避する見積もりとプロジェクト遂行時の１２のアドバイス

Q　少人数のプロジェクトなので、人月で見積もろうと思います。
A　契約形態によります。準委任契約でアウトプットの提出義務がなければよいでしょう。請負契約の場合、人数に関わらず、完成責任を負いますから見積もりできなければ請け負えません。

Q　顧客の予算が少ないので生産性の高いメンバを前提に見積もりました。
A　見積もり時点で生産性の高いメンバを前提することは、プロジェクト実行時にチーミングしたメンバの力量とギャップを確実に起こしますのでやってはいけないことです。見積もりするデリバリーチームの標準的なスキルレベルで見積もりをするか、スコープを調整してください。

Q　見積もりフェーズで要件定義をするというのはどうでしょうか。
A　コスト負担を処理できれば一つの選択肢になるでしょう。ただ、RFPがでているような場合はベンダー側が一方的な要件定義をするようなものです。別の見方をすれば、見積もりフェーズで要件定義をするのは提案依頼書を作成するようなものです。

Q　見積もりフェーズで機能一覧は必要でしょうか。
A　システム概念図、システム方式案、機能概要は必要です。

Q　システム概念図や機能概要は顧客が作るものではありませんか。
A　業務要件や既存システム構成の制約を知っているのは顧客です。提案依頼をするのですから要件と前提条件を提示するのは顧客の義務です。

Q　見積もりにはどのようなコストを含めれば良いですか。
A　直接システム開発に関連する技術サービスコスト、プロジェクト管理コスト、プロジェクト経費を含めます。このほか組織の間接コストを含める必要があります。間接コストには営業コストも含まれます。

Q　デスマーチは要件定義から始まりますか。
A　デスマーチが始まる起点は２つあります。見積もりと要件定義です。要件定義がデスマーチの起点の場合、デリバリーチームに問題があります。

Q　要件定義でシステム要件の抜け漏れがあったときはどうしたら良いですか。
A　要件定義を延長し、システム要件を確定しましょう。それが一番コストインパクトを抑えられます。

Q　プロジェクトは中断や破棄できるものですか。
A　プロジェクトの実行時に契約と違う条件が提示されれば、契約解除をするか、再見積もりをすればよいです。そのようにできることを明示的に記載するのがよいでしょう。

Q　デスマーチは必ず赤字になりますよね。
A　受注金額が高い場合でもスケジュールに実現性がなければデスマーチになります。QCDのいづれかが、妥当な数量を満たさない場合、デスマーチです。

Q　プロジェクトを赤字にしないためにはどうしたらよいですか。
A　契約を履行できる見積もりを作成することです。プロエジェクト実行時は、完成責任を果たせる体制と実行計画を立て、プロジェクト遂行時はプロジェクトコントロールをプロジェクト完了まで行うことがプロジェクトを赤字にしないために必要なことです。

Q　プロジェクトを赤字にしないために必要なことは当たり前なことではありませんか。
A　当たり前なことを当たり前にできないからデスマーチになりますし、赤字になります。