プロジェクト管理における失敗事例①

プロジェクト管理における失敗事例①

プロジェクト管理に求められることは、 一定の品質(Q)で、 決まったコスト(C)のモノを、 決まった納期(D)までに、を提供することである。プロジェクト管理には、様々な管理項目があるが、今回は、あるあるの事例を提供します。

要件定義があやふやで、見積りミスが発生するケース

失敗

一番あることだと思いますが、要件定義がきっちりとできていなくて、後続フェーズでしわ寄せが来てしまうパターンです。

要件定義で、何の課題があって、その課題をどうやって解決するのか、解決するためのソリューション検討や、それで得られる効果が測定されておらず、概要設計で方針がブレはじめ、基本設計でされにズレ、受入テストで思っていたものと違う!!ということが発生する。

モノができるまで、イメージ共用がし辛いので仕方ない部分もありますが、これは言って、発注側と受注側の両方に非があると個人的には思っています。

要件定義以降でズレないようにするためには・・・?

システム開発

100%完璧な要件定義は、できません。様々な要因(例えば、既存システムの仕組み、仕様、関連するシステムの都合など)があり、それを要件定義時点で洗い出すことは不可能に近い作業です。(コストを無尽蔵にかければ別ですが。。。)

そうなった場合にどうするかですが、個人的には以下のような対策を入れています。

  • 工程が変わるときに、全員(発注側、受注側、ステークホルダー)で要件の再確認を行う
  • 仕様変更が発生した場合は、内容と影響範囲の把握、なぜこの要件が出たのかを確認する
  • その工程でのコスト超過があるかどうかを確認する
  • レビューによる品質、関係者の意識のズレはあるかの確認
  • ズレが有る場合は、どこでズレているのか、何がズレているのかを把握し、全員で再度目的をあわせる

基本的なことですが、上記をやれない人が多いですね。誰々がやるから、自分じゃない、担当じゃないなどと理由をつけて。

まぁ個人的には誰がどうやっても構わないと思っていますが、プロジェクトの場合は、プロジェクトマネージャー(PM)が意思決定する。そのために、プロジェクトリーダー(PL)とその配下のメンバーがPMに情報を提供する。これさえできれば、おおよそのプロジェクトはうまくいきます。

次回は、スケジュール遅延か品質劣化か開発側における失敗事例を話そうかなと思います。