プロジェクトあるある（９０）

本日のプロジェクトあるある：

プロジェクトの成果物を明確にしておらず、最終段階で想定していないドキュメントを大量に作成するはめになる

通常プロジェクトを発足するのは、通常業務とは異なり、新しい何かを作り出したり改善したり変更したりすることを目的としています。

このプロジェクトを実行するときには、どこまで何をやるのか、対応範囲（スコープ）を決めます。

そうしないと、追加追加でいろんなものを盛り込んでいたらいつまでも終わらなくなるからです。

スコープの中に定められるものの中に成果物があります。

例えば、システム構築プロジェクトであれば、その構築されたシステムそのものが成果物になります。

それ以外には、ドキュメント類が成果物にあげられたりします。例えば設計書、要件定義書、テスト結果報告書、運用手順書などですね。

これらの成果物は、プロジェクト開始前にきちんと定義し、合意しておく必要があります。

社内プロジェクトならまだしも、社外のプロジェクトを請け負うような場合には特に注意が必要です。

どのようなドキュメントが必要なのか明確にしておかないと、後々にトラブルが発生します。

最後の砦がプロジェクトキックオフです。

ここでプロジェクトの実施内容、スコープ、スケジュール、成果物について確認を取り、関係者で合意を取り付けます。

ただですね、それでもお互いに認識の齟齬というものは起きてしまうものです。

キックオフで合意した成果物の中には含まれていなくても、お客様が「そんなの書かなくても当然含まれるでしょう」と思っているような資料が出てくるのです。

それも、作成しようと思ったらかなり工数のかかるものだったりします。

過去の経験上結構もめたのが

・運用に関する資料
・ユーザマニュアル
・英語版ドキュメント

ですね。

どれもプロジェクト後半から終盤に必要となるドキュメントです。

最初は設計や構築のことに集中していて、実際に運用に入ってからの補助資料や体制についてなにも考えていなかったことにお客様は気付くのです。

そうなると、お客様も必死です。

「そんなの成果物で合意するまでもなく当然用意するものでしょう」

「あなたたちはプロなのに、必要だとわかっている資料が抜けていることを最初に伝えないのは不誠実だ」

「ｘｘｘｘという成果物の中に当然含まれるものと思っていた」

あああぁ。。

これらのセリフ、何度聞いてきたことだろう。。

だいたいのケースでは、お客様の考慮漏れなんです。ただ、それ以上追加予算をひねり出せないからごり押しするしかないということなんですよね。

結局多くの場合はプロジェクト側で対応せざるを得なくなり、メンバーの稼働は跳ね上がり、予算も大幅に超過、なんてことが起きてしまうのでした。

それではまた！

日々感謝 m(_ _)m