| プロジェクトの挫折 |
| 当該システムについては、過去に何回か同じようなシステムを構築したＳＥがメンバーに在籍していたので、厳しい開発工数をなるべく低く抑える為に、ユーザからの要件のヒアリング時間と回数を短くして、すぐにシステム設計に入った。ユーザからもヒアリングなどの打合せ回数が少なくて業務の中断がないので、過去のベンダーよりも優秀であると高く評価された。開発は順調に進み続け、予定のスケジュールをかなり下回ってシステムの基本設計が完了した。ここで本来であるならば、ユーザの承認がないと次のステップには移れないのであるが、経験者もいることなので、ユーザ承認を得ずに経験者の厳密な検証を通して、次ぎの詳細設計のフェーズへと駒を進めた。システムテストも無事終了して納品が完了した。後はユーザの検証を待つのみとなった。ユーザからの中間報告では、特に問題は発生していなかったので、プロジェクトマネジャーは次の新しいシステムの打合せに出席していた。ところが、ユーザがなかなか検証完了してくれないという問題が発生し、結局本番リリースに間に会わなかった為、企業としての信頼と名誉を失ってしまった。 |
| 問題提起 |
| 上記での問題はユーザが検証を完了してくれない事である。どうしてこのような事態が起こるのかと言うと、検証を完了する為に必要な監査項目、つまり、納品成果物の完成品がユーザ側で明確に定義できていなかった事が最大の原因である。 |
| 解決策 |
| ユーザ側の監査項目を定義する事、つまり、ユーザとの間で納品成果物の最終ゴールを決めて置く事は一番大事な事である。メーカーは、一体何を創れば最終的にユーザが承認してくれるのかという事を確実に知る事が必要である。その為に時間を消費する事は無駄な事ではなく、必要な事であるとプロジェクトマネジャー初めすべてのステークホルダー（システムの利害関係者)が理解すべきである。プロジェクトを開始する前と開始してからの各フェーズに於いて、このような時間を必ずとる事を計画に組み入れなければならない。スコープマネジメント、タイムマネジメント、コストマネジメントで考慮する必要がある。また、リスクマネジメントで定義が受け入れられない場合の対策を検討しておく必要がある。 |
| 効果 |
| プロジェクトのすべてに置いて効果が現れる。作業範疇、スケジュール、人員、コスト、品質のすべてに於いて確実に効果が現れる。特に顧客との信頼性は確保される。 |
| 教訓 |
| ■ |
プロジェクトを成功させる為に必要な事は、精度の高い計画、各フェーズでの計画の実践結果の検証、つまり作業品質の確保である。 |
| ■ |
作業品質の確保に於いては検証権限を持ったキーマンの承認が必ず必要である。 |
|
